I actually like the Windows model: Next -> Next -> Next -> Install. .oO(OT: except that now I use .msi files and a silent installation)

I was *so* sure that pg_config provides the socket path. My experience with pg_config comes from psycopg2, which is a different use case.

I guess I’ll have a look around.

This is great. Pure Python libraries are way underrated. Python’s ability to interface with C libraries is great but it’s nice to have pure Python alternatives with no dependencies.

I’ll keep an eye on your project, however, and hope that I can use it in preference to the other modules in the future. It’s true that pyPgSQL does some tests on statements to see if they’re likely to work with cursors, and my patch to psycopg2 does similar things. The big problem with PostgreSQL, in my opinion, is that it’s often very good technically in so many areas, only to be let down by one or two minor details which can “sour the deal”.

For example, pyPgSQL compares queries against regular expressions to determine whether “DECLARE CURSOR” can use the query. This obviously works, but I believe it is inflexible. An SQL command “EXECUTE”, to run a prepared statement, would not use the cursor functionality because it doesn’t match the “SELECT” regular expression. Assuming that the regular expressions in the library are perfect, they wouldn’t be future-proof — what if new versions of PostgreSQL add some new statement that returns a result set? pg8000 would work the same as usual with the new statement.

One of my favourite facts about pg8000 is that it uses the binary data transfer format selectively for some types. For example, floats are transmitted in binary format, which actually has impact on their value as compared to text formats. The bytea type, which isn’t implemented yet in pg8000, will not require escaping the text being sent across the wire. The timestamp type does not work well with the binary transfer format since it can sometimes be a float8, and sometimes not, so the text format is used again. Very flexible type implementation that I am happy with.

For example, bpgsql escapes strings on the client side and builds a complete command to upload to the server, whereas pg8000 uses PG bind variables to avoid having to escape the string. If both are implemented right, I don’t think there’s a practical difference between the two. I believe my approach is more conservative in letting the database server handle what has traditionally been a source of security problems in databases (SQL injection possibilities). On the other hand, creating a DB-API compliant interface that supports another parameter quoting style means that I need to rewrite the query into a new parameter style, which could be a source of obscure bugs too.

pg8000 uses the PostgreSQL “extended query” protocol for queries, which means that prepared statements and cursors come for free. I’ve built the API to represent that, and it has allowed me to reduce memory consumption by caching a limited number of rows from the server response. I think that’s a valuable feature in the library. But it could be done with some clever middleware around any PostgreSQL library.

There are lots of differences between the two libraries. My opinion about them is bound to be biased, as I am proud of my work. Maybe once pg8000 supports DB-API 2.0 we’ll be on even ground to compare the two.

Anyway, congratulations for your pure python approach. To my
understanding, in this field the java people is far far away from
us, because they *believe* in their language. Just in the DB case,
they have all those type 4 drivers for all mayor db vendors.
That’s pure java!. No clients, no deployment nightmare. And this
is even worst in the python world because creating C extensions
for windows can be a headache (because compiler dependences).

So I hope the best for this project (if you open the development
or try to join the psycopg people, there will be more possibilities
of success, but it’s your call).