From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Matt Newell <newellm(at)blur(dot)com> |
Cc: | PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq pipelining |
Date: | 2014-12-04 19:30:27 |
Message-ID: | CAGTBQpb9vrR04w7ybwxVqAmd_VtUatWGrbMWLA2D9EYRE3i0bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell <newellm(at)blur(dot)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.
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.
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).
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2014-12-04 19:44:59 | Re: Bugfix and new feature for PGXS |
Previous Message | Matt Newell | 2014-12-04 19:11:19 | Re: libpq pipelining |