Tackling a few subjects here, so this might be a bigger post than usual.
First, there has been some work with PGSQLKit over the last couple of months that we need to talk about. While much of the work has revolved around getting everything working so that the iPhone / iPad can be used as clients to a PostgreSQL database, there has also been a good bit of work to address several other issues. One that comes up fairly often is the ability to store binary data. Though we haven't finished the PreparedStatement work (we still haven't found a solution for this we really like), we did add a pair of new functions to the PGSQLConnection object to make it easier to manage binary data.
-(NSData *)sqlDecodeData:(NSData *)toDecode;
-(NSString *)sqlEncodeData:(NSData *)toEncode;
These two functions work in tandem to encode and decode binary data for use in sql commands. While storing large amounts of data in binary form is not really what PostgreSQL is designed for, it works well for small amounts of binary data.
In addition, all of the objects have been altered to allow for better support of string encodings. For PostgreSQL9, we are moving towards using a local platform mapping to determine a default encoding based upon your locale. Most programs that use PGSQLKit will need to call setDefaultEncoding: to ensure correct string encoding operations as the defaults will change to NSUTF8String with PostgreSQL9.
iPad / iOS
The iPad and iOS4 platforms present some interesting issues for us. At this point, everything in PGSQLKit but PGSQLLogin works on iOS3 and iOS4. However, because frameworks are not supported, the classes have to be imported as source. We hope to have a sample project uploaded in the coming months to show how all of this works.
The flip side to this however, is the server. We get frequent requests to run PostgreSQL itself on the iPad. Though in our testing, it is something that *could* be done we are not entirely sure if that translates to *should*. First, battery life would be impacted. Second, for single user needs, is this necessarily a good answer? Third, assuming that it was all configured and running, what are the real applications the PostgreSQL engine on the iPad?
At this point, we do not have good answers, and so this part of the project will, for the immediate future at least, remain more of a theoretical / proof of concept project. If we see a compelling reason to change this, we will.
PostgreSQL9
With PostgreSQL9 having recently moved to Beta2 stages, we are expecting a release sooner than later. This means that we are gearing up to deliver a new installer, that hopefully addresses most of the weaknesses of the current approach. At this point, we think we will have something ready to go about 4 weeks after the official PostgreSQL9 release, but as always, the paying work will take precedence.