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

On Tue, 2008-04-08 at 22:06 -0400, Merlin Moncure wrote:
> 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?
> 

You're starting to convince me on this point, but the instability of
external binary representations between versions is still worrisome.

> 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.

There are many cases that are fairly hard to get a perfect mapping. If
you use PGtime, for instance, there are no C operators for it, so
you're basically just getting the data in binary format. That can be a
benefit in many applications, but that's an argument for allowing
binary-format results, not for implicitly casting from one type to
another.

If you try to use the C time type instead, you will have many more
operators available, but will lose precision. That's OK for many
applications, but not a general solution.

And I think NULL is still particularly tricky. If you have to check
each field explicitly anyway, it doesn't seem to save a lot of effort
to implicitly cast the value. In ruby-pg, I return nil for a NULL, and
I think that works fairly well because almost any operator will
immediately fail on nil (in Ruby), so mistakes are caught quickly. If
we're casting NULL to 0, and then have to check to see that it's NULL,
that seems as error-prone as libpq is currently.

I think the heart of this problem is that the mapping works great
except where the types don't quite match up. To remember what types fit
and how well they fit, you have to refer back to other code or docs. To
really make the types match up well would be a huge effort.

> >  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.
> 

Agreed. Again though, that's an argument for allowing binary-format
results.

Regards,Jeff Davis