Simon Kirk wrote:
... The PostgreSQL drivers for Squeak seem to encapsulate a nice generic framework from which base other pure Squeak database drivers, but whoever developed it never did the required abstraction: I wonder if anybody ever did it, started it, or even considered doing it?
The "PostgreSQL Client for Squeak" internal design is based on the well-documented Postgres frontend/backend protocol. What might be somewhat novel is to treat each protocol message as an event that triggers a state-machine transition. The state-machine is depicted here: http://ca.geocities.com/yanni@rogers.com/pgsqueak/PGConnection.5.gif
Since I don't know the internals of any other database connection protocol, I don't know whether it's a suitable generic framework for other databases.
Also, what sort of "required abstraction" are you looking for? Is it a layer that might sit between GLORP and any other relational database? If so, then IMHO it's not a requirement for either GLORP or the postgres client. However, it's certainly a useful abstraction layer to have if you want to plug different databases into GLORP. I'd probably consider working on the layer, the moment I needed to hit a different relational database. It's possible that the methods in the "api" category of PGConnection and the PGResult & PGResultSet could form the basis of such an abstraction layer.
--yanni
P.S. I just recently happened to try the PostgreSQL client with a version 8.1 server. I found I had to do two things: (1) Make sure pg_hba.conf is set to use "password" authenticaton instead of the default "MD5". (2) Make sure a password is set, a 'nil' password no longer works.