ANN: Postgrehx, a pure-haxe implementation of the Postgres wire protocol

450 views
Skip to first unread message

Justin Donaldson

unread,
Sep 3, 2013, 1:21:46 AM9/3/13
to Haxe
I put together a postgres library this weekend, enjoy!

https://github.com/jdonaldson/postgrehx

It's still pretty rough, and the haxe Connection interface is not implemented completely.  I'll post some of my questions on that soon.

There's some neat things that are possible here, particularly with postgres' richer datatype spec; E.g its ability to query and return json objects.

Best,
-Justin


Juraj Kirchheim

unread,
Sep 3, 2013, 4:21:10 AM9/3/13
to haxe...@googlegroups.com
Awesome!
> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Haxe" group.
> For more options, visit https://groups.google.com/groups/opt_out.

Justin Donaldson

unread,
Sep 5, 2013, 1:35:33 AM9/5/13
to Haxe
for sys.db.Connection, I would think quote() would simply quote a string (e.g. escaping single quotes with doubles, etc.), and escape() would escape any potentially malicious string values (quotes, new lines, backslashes, etc.).  In the std SqlLite implementation, it looks like it's the opposite.   Do I have things backwards?

Best,
-Justin

Marcelo Serpa

unread,
Sep 5, 2013, 1:50:01 PM9/5/13
to haxe...@googlegroups.com
Very nice! I can't remember the last time I used MySQL. PostgreSQL is what I have been using and I it's rock solid. Nice to see some support here. 

What platforms are currently supported?

-- 
Marcelo

Eric Priou

unread,
Sep 5, 2013, 2:18:17 PM9/5/13
to haxe...@googlegroups.com

Justin Donaldson

unread,
Sep 5, 2013, 4:57:31 PM9/5/13
to Haxe

>
> What platforms are currently supported?

Anything that supports the basic Haxe sys module should work.  I've done quick tests on neko php and CPP.

Some platforms seem faster.  I wonder if Haxe could provide its own cpp externs within the sys module?  E.g. a compiled CPP extern used by neko...

Best,
Justin

Justin Donaldson

unread,
Sep 5, 2013, 5:16:52 PM9/5/13
to Haxe

Also worth mentioning... I believe this should all work inside of macros as well.  It could make for an interesting orm.

Jason O'Neil

unread,
Sep 5, 2013, 7:00:18 PM9/5/13
to haxe...@googlegroups.com

Nice approach...

Doing it completely in Haxe using sockets rather than wrapping ndlls or native libraries is cool, and really allows it to work cross-platform in a fairly reliable way.  Once this gets a bit more stable it will be interesting to see what is needed for it to work with Haxe's DB macros.  Mostly the macros just generate SQL statements, but until now they've only been tested against MySQL and SQLite, so supporting Postgres support may require a few changes...

Postgres support should also be possible on the Java target via the JDBC driver once Cauê merges his pull request... But a native "haxe" implementation is just so cool :)

Jason

cool

Juraj Kirchheim

unread,
Sep 6, 2013, 7:37:21 AM9/6/13
to haxe...@googlegroups.com
The library implements sys.db.Connection, so technically, it can work
with Haxe's DB macros already.

But there's still work to be done, especially for decoding primitives.
At the current stage, I wouldn't be surprised if things like Dates are
not correctly converted.

Regards,
Juraj

Jason O'Neil

unread,
Sep 6, 2013, 8:51:30 AM9/6/13
to haxe...@googlegroups.com
I'm aware that the DB macros have some connection specific hacks in them, especially the TableCreate class, but in a few other places as well.  At the moment I've seen these workarounds for MySQL and SQLite, so there would just have to be some testing (or thorough examination of the code) to see where these occur and where they don't.

As more connection types become available it would be worth looking to minimize these hacks, and the other thing I would like to look at is having them work with an Async connection for NodeJS.  All in good time :)


Cauê Waneck

unread,
Sep 6, 2013, 9:07:05 AM9/6/13
to haxe...@googlegroups.com

2013/9/6 Jason O'Neil <jason...@gmail.com>

I'm aware that the DB macros have some connection specific hacks in them, especially the TableCreate class, but in a few other places as well.  At the moment I've seen these workarounds for MySQL and SQLite, so there would just have to be some testing (or thorough examination of the code) to see where these occur and where they don't.

Yes. It comes into my mind specifically the TableCreate class, and the MySQL-specific way to deal with locks and LIMIT. Limit's particularly painful to deal with, unfortunately. 

As more connection types become available it would be worth looking to minimize these hacks, and the other thing I would like to look at is having them work with an Async connection for NodeJS.  All in good time :)

That'd be awesome, Jason! By the way, just came to know your ufront.db package, and that's very useful, thanks! 

Justin Donaldson

unread,
Sep 15, 2013, 10:38:39 PM9/15/13
to Haxe
Hey folks, just wanted to mention that postgrehx has a starter test suite now.

I got it integrated with travis-ci thanks to this great blog post by Andy Li:

I'm only testing neko for now, but I'll try to run the full suite on all compatible targets soon.

Best,
-Justin

Cauê Waneck

unread,
Sep 16, 2013, 3:41:34 AM9/16/13
to haxe...@googlegroups.com
Very nice, Justin! Thanks!
I'm really starting to like pure haxe implementations - much more than using native glue code. 
Thankfully for us, the nodejs community has lots of those implementations we could port - like a mysql one!

Thanks!
Cauê
Sent from Gmail Mobile

Justin Donaldson

unread,
Sep 21, 2013, 1:02:23 PM9/21/13
to Haxe

A quick update on postgrehx,  I've rewritten the results processing so that it is completely iterator based.  This means that individual records are retrieved off the socket as they are requested, rather than all at once.  The iterator can also be aborted, and subsequent requests will automatically discard the remaining socket messages from a previous request.  If you want the record results as a collection, you can call "results()" normally as part of the ResultSet api.  

Side note:  If you call "length()" on the ResultSet api, the remaining results will be cached to an array, and counted (Postgres doesn't tell you how many results it retrieves until the very last record has been returned).


This should make the library work much better with asynchronous methods.  However, there still can be long back end delays after certain queries (deletions, etc.), so there's still work to do there.

Best,
-Justin

Justin Donaldson

unread,
Dec 5, 2013, 9:21:23 PM12/5/13
to Haxe
One more update on postgrehx, the pure haxe postgres library:

theRemix has helped me identify and patch a number of problems, and I think the library is approaching an "alpha" state in terms of functionality.

There's still large parts of the wire protocol that are unimplemented, but for the most part the basic query/response protocol is done.

Recently I've gotten Spod working, as well as providing more robust support for "interrupted query result retrieval" (i.e. cleaning up abandoned query results still remaining on the socket).  I've even started experimenting with Postgres's new json datatype and functions, which I think could really change the way that Haxe can interact with a database.

Best,
-Justin
 

theRemix

unread,
Dec 8, 2013, 2:08:45 AM12/8/13
to haxe...@googlegroups.com
Yes thank you so much for working hard on this.

I'm testing it a lot and i'm excited about this project.
Reply all
Reply to author
Forward
0 new messages