Re: [PATCHES] libpq type system 0.9a - Mailing list pgsql-hackers

On Tue, Apr 8, 2008 at 9:21 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>  I looked into this today.
>
>   * Arrays and composites
>
>  Better ability in libpq to parse and construct arrays and composites
>  would be helpful. I think this is worthwhile to consider, and I would
>  expose the functionality (at least for arrays) in ruby-pg if available.

Right..that was the principle objective.  In our particular case we
move a lot of data in and out via arrays, and in certain case moving
data in and out via binary is a huge performance win.

>   * Binary formatting
>
>  The exclusive use of binary formats is worrisome to me. This circumvents
>  one level of indirection that we have (i.e. that everything moves
>  through in/out functions), and will impose a backwards-compatibility
>  requirement on the internal representation of data types, including
>  user-defined data types. As far as I know, we currently have no such
>  requirement, even for built-in types.

This is a valid concern. That said, the in/out functions don't change
_that_ much, and even if they did..there are solutions to this
problem.  Forwards compatibility is the worst case (8.4 libpq
connecting to 8.5 server).  If this problem was reasonably addressed
though, would it alleviate your concerns?

>   * Type conversion callbacks
>
>  The type conversion hooks make some sense, but I have reservations about
>  that policy as well. The data types in PostgreSQL will never match
>  perfectly the data types in a host language -- NULL in particular
>  doesn't have a direct counterpart.

>  If there were a perfect mapping of types, it would seem like a much
>  better idea. The problem is that we don't want to have some types that
>  are perfectly mapped (e.g. int, bytea), some that are imperfectly mapped
>  (e.g. dates, numeric), and some types that have no conversion defined
>  and fall back to something else. In this case, the result format is
>  always binary, so we can't even fall back to text.

We introduced types for which there were no native
counterparts...PGtime for example,   This choice of which types map
and which don't is fairly arbitrary, but not terrible from libpq
perspective.  We could for example typedef int to PGint, or PGint4 to
make things more consistent, I suppose.

I would suggest that if you want text from the database, cast it as
such in the query and pull it with %text.

>  In my experience trying to implicitly map to types doesn't save a lot of
>  time for the developer. You end up spending time referencing the
>  documentation (or some other part of the code) to figure out how the
>  edge cases are being handled rather than just handling them explicitly
>  in the code. For instance, wrapping a value you expect to be a date in
>  Date.parse() is more readable in most cases.

There are many types where this is not the case.  Consider the
geometric types for example.  There is little reason to pull these in
text and farily large performance benefits to retrieving in binary.

merlin