Now that we have the major hurdle of getting the base PostgreSQL distribution back up to current code, we can now tackle the long desired enhancements to the PGSQLKit.
As I see it, there are four projects that need to be addressed in the PGSQLKit as is stands. First and foremost is documentation. Second is to enhance the system to better cope with String Encodings (in both default and per use forms). Third is to establish a better method for binding a recordset to an Array. Fourth is to implemented an object and method for using Prepared Statements.
Two of these are relatively straightforward. The other two are pretty massive undertakings.
Documentation pretty much has to be the highest priority, and it needs to come in two forms. It needs to be easily used on the development machine, but it also needs to readily available on the web. The former can be addressed with the already begun move to using HeaderDoc, but the second is a manual process as it will require some work to convert the HeaderDocs into something that is easily integrated into the website.
The String enhancements may actually be released before the documentation, simply because much of the work is already in place. We have already done the work in ODBCKit, so translating that to the PGSQLkit really isn't that much work.
Dealing with the bindings issue is a little more complex. At the heart of the issue is be nature a recordset is a largely a forward read environment. In order to make this a data source, it would need to prefetch the content. While this is feasable for smaller results, when we start talking 1.2 million records at 30kb per record, it suddenly becomes a nightmare. After some discussions regarding the potential pitfalls, we really do not have a consensus answer. The easy answer is to simply say, create a Data Source class that can be fetched off a recordset. and let the developer deal with the consequences of creating a DataSource that contains too much data.
The second part of this is, should a DataSource be updatable? This is a tricky one. Eventually, it should be allowed (where possible) but it starts into a bit of code that is much more prone to error than anything read only. This will not be a part of the first pass at this.
Last is the implementation of Prepared Statements. Honestly, if someone else wants to tackle this, feel free to speak up. We have been through 4 iterations of design on this for the ODBCKit and none have been good solutions. They are either too complex, or not powerful enough. There does not seem to be a reasonable middle ground.
Also of note, the next major version of PostgreSQL is no longer labeled as 8.5, it is now 9.0 and has started Alpha level testing. With that launch, we will move the PostgreSQL8 folder to PostgreSQL/versions/ to ease future transitions.