Re: PGparam proposal

Andrew Chernow <ac(at)esilo(dot)com> writes:
> This proposal extends libpq by adding a printf style functions for
> sending and recveiving through the paramterized interface.

I think a printf-style API is fundamentally a bad idea in this context.
printf only works well when the set of concepts (datatypes, format
specifiers, etc) is small and fixed; neither of which adjectives
describe PG's set of datatypes. You've already had to go to
two-character format codes in order to have even slightly mnemonic codes
for the most commonly used built-in types; that doesn't look like it's
going to scale up for long. And what are you going to do about add-on
data types, such as contrib stuff, PostGIS and other add-on projects,
or user-defined types?

> PQputf offers a way of packing pgtypes for use with the parameterized
> functions. One or more values can be put at the same time. The params
> are stored within the PGconn struct as a PGparam structure (internal
> API only). The paramspec describes the pgtypes that you want to put.
> In the paramspec, anything other than a valid conversion specifiers is
> ignored. "%n4, -(at)#= %n8" is treated the same way as "%n4%n8".
> Once all params have been put, one of four paramterized functions that
> are aware of PGparam can be used:

I find the idea of embedding state like that into the PGconn to be
pretty horrid, as well. It makes the design non-reentrant --- consider
the example of wanting to execute a query during the process of
computing parameters for a later query. If there's merit in the idea
at all, expose PGparam as a separate (but opaque) data structure that is
explicitly passed into and out of the functions that are concerned with
it.

> * PQexecParams
> * PQexecPrepared
> * PQsendQueryParams
> * PQsendQueryPrepared

You can't just randomly change the behavior of existing API functions.

> Date and time types:
> dt time, timetz
> dd date
> dT timestamp, timestamptz
> di interval

I'm not sure whether timestamp/timestamptz can or should be treated
as interchangeable; but time and timetz definitely are not.

BTW, how will this code react to the inevitable future changes in
binary formats? As examples, show what you'd do with

* the 8.2-to-8.3 change in the width of type money

* the likely future change to type timestamptz to store original
timezone explicitly

* the likely future change to type text to store encoding/collation
info explicitly

If the answer is that libpq will be unable to deal with these
events, I think the proposal is dead in the water. There's a reason
why we aren't pushing client-side use of binary formats very hard:
in many cases those formats are subject to change.

There might be some value in the concept of building up parameter
values in a PGparam object before passing it to an eventual PQexec-like
function. However, I see no reason to tie that concept to the
use of binary parameter format.

regards, tom lane