From: Matt Newell <newellm@blur.com>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Subject: Re: libpq pipelining
Date: Thu, 04 Dec 2014 11:45:28 -0800
Message-ID: <12660098.ITZryZyikI@obsidian> (raw)
In-Reply-To: <CAGTBQpb9vrR04w7ybwxVqAmd_VtUatWGrbMWLA2D9EYRE3i0bg@mail.gmail.com>
References: <2059418.jZQvL3lH90@obsidian>
<4208748.4mnkvVCjOB@obsidian>
<CAGTBQpb9vrR04w7ybwxVqAmd_VtUatWGrbMWLA2D9EYRE3i0bg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: newellm@blur.com, klaussfreire@gmail.com
Subject: Re: libpq pipelining
In-Reply-To: <12660098.ITZryZyikI@obsidian>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox