Here is our updated PGparam extension to the libpq api:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00356.php
We have a patch implementing the following which we are cleaning up. We
are also kicking around some ideas for arrays and possibly composite
types which we may consider if
For starters, if binary results is a feature you wish you could uninvent
then we are probably dead in the water for that reason. This goes to
the core of our concept. If there is no desire to synch client server
in regards to type handling, than this a waste of time. I think all of
this
Andrew Chernow [EMAIL PROTECTED] writes:
For starters, if binary results is a feature you wish you could uninvent
then we are probably dead in the water for that reason. This goes to
the core of our concept.
Not really: AFAICS you could implement exactly the API you have sketched
without
library users would have no idea whether
the values they provide are being sent as text or binary.
The putf interface currently abstracts how it actually sends it.
Although, you do put a C type rather than a string. There is a putstr
%pqtypstr, which puts the string representation of a type.
your proposal completely glossed over the
issue of exactly what data structure would be exposed to clients for
anything more complex than an integer
Yeah. Forgot to include the below in the proposal and the last email.
Here is the lastest list for complex types. Most have been around since
We will have a 0.6 patch tomorrow. This is not a patch, its a proposal.
The implementation has been adjusted and is now a simple printf-style
interface. This is just a design proposal to see if people like the
idea and interface. Up to this point, we have not provided a formal
proposal;
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
