Re: [PATCHES] libpq type system 0.9a

On Tue, Apr 8, 2008 at 3:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Chernow <ac(at)esilo(dot)com> writes:
> > Tom Lane wrote:
> >> Better support for arrays and composites is certainly something that
> >> people might want, but the problem with this design is that it forces
> >> them to buy into a number of other decisions that they don't necessarily
> >> want.

> > What decisions are we forcing upon the libpq user?
>
> Well, for starters, using binary format. It is undeniable that that
> creates more portability risks (cross-architecture and cross-PG-version
> issues) than text format. Not everyone wants to take those risks for
> benefits that may not be meaningful for their apps.

personally, I think these claims of portability are a bit
overblown...they are trivially checked by regressions tests. the
version question is more interesting and solutions range from the easy
(force version match to access binary types) to the complex.

> The other forced decision is the whole PQputf/PQgetf notation, which
> people may or may not find natural --- it still seems a pretty poor
> choice to me for this specific problem. PQputf, in the form where
> you're generating a SQL command string along with some parameters,
> isn't too unreasonable, but unless you've already bought into binary
> parameter handling it's not gaining all that much either. And
> PQgetf is just weird. The format of a PGresult is generally well
> known by the app; trying to force it into the model of string
> scanning is a poor fit. For instance there's no mapping at all
> for what to do with constant parts of the format string.

We chose to do the PQgetf function that way as a compromise of many
different requirements (we went through several alternative
implementations before settling on the final one). At minimum, you
have to supply at least _some_ type information because getf writes
into application memory, and aside from the obvious safety issues,
there are user defined types to consider.

Since you can register additional type into the handler system at
runtime (including 'automagic' discovery of composite types by name),
there has to be some way of directing the library to the proper
handler. Since everything is driven by typename, it all comes down to
how you want to do this. We like the varargs style since it provides
some symmetry with putf and feels 'right' in coding.

The only other approach to getf that meets all the requirements would
be like this:
PQgetf(result, tup_num, "date", 0, &date); // not varargs

where the typestring is fixed to one type...you could only pull out
one parameter at a time (no variable argument list). We considered
this carefully, and we opted for the submitted approach as the best
solution. One other benefit to doing things this way is we get to
alter the 'format escape character, (%)', to # when lookup by name as
opposed to column position is desired.

The constant part of the format string in getf are ignored, they have
no meaning in that context. Same with putf. Although, there is
PQputvf which will take something like this: "select %int4 + %int4"
and turn it into "select $1 + $2". In PQputvf, everything surrounding
the type modifier is still ignored. So, the API is symmetrical in
terms of type string, except that for query execution there is an
extra stage where the query string is mapped. What you find to be
weird here I think is rather elegant :-).

>>PQputf/PQgetf notation, which
> people may or may not find natural --- it still seems a pretty poor
> choice to me for this specific problem
We reference types by there name (can include schema as well). There
is no better mnemonic than that ... is there? For example, if I have
some funky type 'foo' defined on the server, what is more natural than
pulling that type with %foo (which can be optionally schema
qualified)?

By the way, we ended up with the current implementation based on your
concerns with previous attempts (using two letter format codes, or
exported static type handlers)...(we really like how things turned out
though...using schema qualified type names as the 'typespec' really
makes the libpq code look 'pretty'.

merlin