From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Chernow <ac(at)esilo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Subject: | Re: PGparam proposal |
Date: | 2007-12-11 00:35:50 |
Message-ID: | 22513.1197333350@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2007-12-11 01:01:31 | Re: partitioned table query question |
Previous Message | Andrew Chernow | 2007-12-11 00:22:32 | Re: PGparam proposal |