On Thursday, December 04, 2014 04:30:27 PM Claudio Freire wrote:
> On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell <newellm@blur.com> wrote:
> > With the API i am proposing, only 2 new functions (PQgetFirstQuery,
> > PQgetLastQuery) are required to be able to match each result to the query
> > that caused it. Another function, PQgetNextQuery allows iterating
> > through the pending queries, and PQgetQueryCommand permits getting the
> > original query text.
> >
> > Adding the ability to set a user supplied pointer on the PGquery struct
> > might make it much easier for some frameworks, and other users might want
> > a callback, but I don't think either are required.
>
> With a pointer on PGquery you wouldn't need any of the above. Who
> whants the query text sets it as a pointer, who wants some other
> struct sets it as a pointer.
>
libpq already stores the (current) query text as it's used in some error
cases, so that's not really optional without breaking backwards compatibility.
Adding another pointer for the user to optional utilize should be no big deal
though if everyone agrees it's a good thing.
> You would only need to be careful about the lifetime of the pointed
> struct, but that onus is on the application I'd say. The API only
> needs to provide some guarantees about how long or short it holds onto
> that pointer.
Agreed.
>
> I'm thinking this would be somewhat necessary for a python wrapper,
> like psycopg2 (the wrapper could build a dictionary based on query
> text, but there's no guarantee that query text will be unique so it'd
> be very tricky).
While it might make some things simpler, i really don't think it absolutely
necessary since the wrapper can maintain a queue that corresponds to libpq's
internal queue of PGquery's. ie, each time you call a PQsendQuery* function
you push your required state, and each time the return value of
PQgetFirstQuery changes you pop from the queue.