Re: Using real libpq parameters

On Sat, Feb 26, 2011 at 11:47 PM, A.M. <agentm(at)themactionfaction(dot)com> wrote:

> Have you looked at libpqtypes? It makes dealing with complex datatypes trivial.
>
> http://libpqtypes.esilo.com/

Hi A.M.,

David Blewett had suggested the same just a few hours before you :)

Maybe I'm missing something about libpqtypes: in this case some
explanation would be appreciated.

What I see is that it offers printf/scanf style parameters passing.
This is greatly helpful if you have C variables containing the
parameters: it saves building the arrays to be passed to PQexecParams.
>From their example:

PGresult *res = PQexecf(conn,
"INSERT INTO t VALUES (%int4, %text)", 654321, "some text");

this seems saving getting the oid of the types, converting the
non-string parameters to string and handling the arrays PQexecParams
requires. But I don't see how psycopg could use this handy function
because there isn't a C function containing the parameters. To
simplify what we have, let's say there is a Python tuple 't'
containing the values all as strings: using such structure would be
something like:

char *paramValues[PySequence_Size(t)];
for (i = 0; i < PySequence_Size(t); i++) {
paramValues[i]
}
PQexecParams(query, ..., paramValues, ...);

(omitting everything about types handling). How could PQexecf be
called given the parameters in the Python tuple t instead of in
separate C variables? Would it be a pattern easier than the one above?

About the types, using the bare libpq, psycopg should iterate over the
python types in input and map every python type into a numeric OID
(about which psycopg already has knowledge), pack them into a C array
and send it as paramTypes. Using libpqtypes instead psycopg should
map the python types into a string - the Postgres name of the types -
and then mangle the type names into the query string. I don't see
particular saving in doing the latter instead of the former: there is
still types mapping to do, and the result should be sprintf'd into a
new query instead of put into a C array - it seems more clumsy.

So, I think libpqtypes is a huge saving for a program that would need
otherwise a lot of bureaucracy to operate with the libpq (knowledge of
the Postgres types etc). But psycopg has already sorted out this kind
of layer.

Then, you may be referring to some different libpqtypes functions and
I may have misunderstood both David's and your advice. In this case I
would be grateful if you could illuminate me about what part of
libpqtypes would be great for psycopg to use: I may be too focused on
PQexecf and completely missing the forest for the trees.

Thank you very much.

-- Daniele