Re: [PATCHES] libpq type system 0.9a

On Wed, Apr 9, 2008 at 6:13 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> > 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 actually incorrect. Binary I/O still goes through a function call, the
> send/recv functions instead of the in/out functions. In theory these are also
> supposed to be cross-platform.
>
> In practice they are, uhm, less cross-platform. For example they send floats
> as raw (presumably) IEEE floats. There have also been fewer clients using
> binary mode, so you're more likely to run into bugs.

small correction: you _were_ more likely to run into bugs. in the
process of developing this patch during the 8.3 cycle, we caught,
fixed, and submitted a number of binary format related issues,
including some wacky things that are not possible through the text
parser (a polygon with zero points for example). we used regression
testing heavily in development.

> But the reason fewer clients use binary mode is because they would have to
> implement all this type-specific knowledge. It doesn't make sense to do it for
> every driver or application but if you're implementing it once in a library it
> does start to make more sense.
>
> Note however that not every data type will necessarily provide a binary
> send/recv function. The built-in data types do, but only as a matter of
> policy. It's not an error to create a type with no binary i/o functions.
> So I think you have to support using text mode as an option.

You have this option. there is nothing keeping you from using getvalue
vs. getf. However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return 'void'. So, at
present, to use PQgetf, you result set must be binary.

In some of the early versions of the patch we introduced parsing code
to compute text results in addition to binary results (so for
getf('%int), the library does the atoi for you, checking range and
such). We ended up dropping this because we were getting nervous
about the size of the patch at that point.

In any event, I think a better solution would be to change
resultformat to mean 'give me binary format if it's available' on a
per column basis...libpq already has a method to check field format of
the result and getf can just raise a run-time error if you try to pass
a native type in when it's not available. This would be a pretty
amazing sequence of events...only likely to occur when developing new
types for example. Is this (mixed text/binary results) possible with
the v3 protocol?

merlin