So this week has seen a handful of additional changes to PGSQLKit. PGSQLKit 8.4.2c has been published with this posting. As we work forward with getting our iPhoneOS work done, we have been spending a lot of time in PGSQLKit (as it is what we are using in the iPhoneOS world). That time has seen us finding little issues but also time to make some needed tweaks.
Most of our work right now is subtle changes like replacing NSMutableStrings that aren't with NSStrings, or identifying release/retain pairs that are not properly matched. Some of the work though is addressing issues raised. If you have been following some of the discussions in the comments of the recent posts, you'll see that we have had the string encoding bugbear rise again.
String Encoding
We addressed this in a simple form not too long ago, but it was just that, a simple quick answer. This update addresses the situation in a more complete way, and lays the groundwork for the future with regards to future usage. The downside is that people using the PGSQLKit today that expect a certain behavior will need to adjust to something new when PostgreSQL 9 is available.
The fundamental change is that effective with 8.4.2c, PGSQLKit now implements a defaultEncoding on all of the objects, starting at the PGSQLConnection object. The default is NSMacOSRomanStringEncoding to remain consistent with the old behavior. Please note, THIS WILL CHANGE WITH PostgreSQL 9.
If you change the defaultEncoding before opening a PGSQLRecordset, all of the string operations on will adopt the new default. Existing PGSQLRecordsets will not be effected, but can be changed by setting their respective defaultEncodings.
What this means is that if defaultEncoding is changed, then all string operations will use the new encoding unless explicitly overriden in cases like using PGSQLFields asString:(NSStringEncoding)encoding method. It also means that using dictionaryFromRecord will return strings using the defaultEncoding.
The defaultEncoding can be altered at any level and always cascades down: Connection -> Recordset -> Record -> Field.
This solution should provide enough power and flexability to deal with most any encoding issues in the future.
Now about the change:
With PostgreSQL 9, the default value for defaultEncoding will change from NSMacOSRomanStringEncoding to NSUTF8StringEncoding.
Documentation
As we continue the work, we are expanding the headerDoc documentation. This documentation is included in the PGSQLKit download, and will eventually find it to the website. The only reason it is not there now is that we have not had the time (or inclination to be honest) to sit down with a CSS editor to really clean up the layouts. It will happen, it just hasn't yet. If someone with a flair for CSS and HeaderDoc has the time and inclination, I promise we won't complain :-).
libpqtouch?
So, unless you didn't catch it, libpqtouch is a version of libpq compiled as a static library that we are using as the foundation of PGSQLKit for the iPhoneOS. The discussion around the office is how to handle this. Right now, the project is a manually updated build of libpq that is built in Xcode to create an armv6 build of libpq. None of us have been able to get a good build of libpq directly from the command line using PostgreSQL sources without eventually hand assembling the files.
This makes it very difficult to publish the changes back to the PostgreSQL community. So, what we are proposing is this: Publish the steps and the Xcode project. Until things stabilize with our project, we are holding on to the work, but hope to get it into the public SVN as soon as we submit the iPad application to the iTunes App Store.