Andrew Chernow <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] %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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
