alaisi/postgres-async-driver — pull request #2 by moea (2014-11-27 04:44:55+00:00)
Title: Type conversion for arrays

Hey - thanks again for this library.

This branch implements conversion of n-dimensional arrays going into and out of the database, with the help of some modified parsing code ripped out of [pgjdbc](https://github.com/pgjdbc/pgjdbc).

I don't know whether this is a feature you're interested in incorporating, however either way I'd very much appreciate some feedback on how best to integrate it, either as a feature or a separate library.

High level stuff:

There's an object used for both insertion and retrieval, `PgArray`, which is given either an array (for insertion), which it converts to a string using a pretty simple and predictable couple of methods, or is given a string (for parsing) and an OID, and returns an `Object[]` (arbitrarily nested), where the leaves are the result of delegating the element parsing to `DataConverter`.

That's the main sticking point as far as integration - the array converter's constructor accepts a `DataConverter` (which is constructed vanilla in the tests, just to get the thing working), but ideally we want it to have access to the pool's converter, so it can parse arrays of types which are themselves converted by user code.

I wrote this for use from Clojure/`postgres.async`, but touching `DataConverter` seemed like the wrong thing to do, and I think I may be missing something as far as how, in Java, it would practical to have the `.get` which happens during the CLJ map conversion correctly invoke `ArrayConverter`. Obviously if this feature ends up in your library, it would be possible to add more clauses to the switch in `toObject`

Anyway, I'm super open minded about making changes, etc. - so please let me know if you can imagine any problems.

Todo:
It'll be a quick change, but I think strings are constructed in a few places without passing in a codec, which could cause problems. Will revisit tomorrow.

More notes:

The largest changes I made to the `pgjdbc` utilities are as follows:
* The JDBC stuff queries the database for type-specific array delimiters before parsing. I wanted to avoid doing that at all costs. I'm also unable to determine in what situations the literal delimiter for an array would be anything other than a comma, so I'm mostly not worrying about it. I checked the catalog in a few varied PG installations for type delimiters, they're all commas, and the only references I can find online are about alternative delimiters with can be used when parsing/constructing strings from/to arrays, which is something different.
* I removed pretty much everything from [buildArray](https://github.com/pgjdbc/pgjdbc/blob/master/org/postgresql/jdbc2/AbstractJdbc2Array.java#L516) - including the facility for constructing primitive arrays, and for declaring the arrays as anything but `Object[]`. Without having a mapping from OIDs to converter return types (including types constructed by custom converters), I think the only other approach to this would be to defer array creation until we can reflect the return type. I'm open-minded about this.
* PG 8.3+ supports `NULL` as an array element. I removed the version checking, so the `NULL` will go to the DB regardless of its version. It works fine both in-and-out post-8.3.