Re: Using real libpq parameters
От | Daniele Varrazzo |
---|---|
Тема | Re: Using real libpq parameters |
Дата | |
Msg-id | AANLkTimjh3nHLabzk_NyEW_6B4hnKn0uY=FD7mUv5Mn3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using real libpq parameters ("A.M." <agentm@themactionfaction.com>) |
Ответы |
Re: Using real libpq parameters
(Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Re: Using real libpq parameters ("A.M." <agentm@themactionfaction.com>) |
Список | psycopg |
On Sat, Feb 26, 2011 at 11:47 PM, A.M. <agentm@themactionfaction.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
В списке psycopg по дате отправления: