From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Matt Newell <newellm@blur.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: libpq pipelining
Date: Fri, 5 Dec 2014 12:22:38 +0200
Message-ID: <5481876E.3000701@vmware.com> (raw)
In-Reply-To: <2193114.W6sD3Nzkqp@obsidian>
References: <2059418.jZQvL3lH90@obsidian>
<5480D476.2090306@vmware.com>
<5812260.A9DG1YyGp2@obsidian>
<2193114.W6sD3Nzkqp@obsidian>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 12/05/2014 02:30 AM, Matt Newell wrote:
>>
>>> The explanation of PQgetFirstQuery makes it sound pretty hard to match
>>> up the result with the query. You have to pay attention to PQisBusy.
>>
>> PQgetFirstQuery should also be valid after
>> calling PQgetResult and then you don't have to worry about PQisBusy, so I
>> should probably change the documentation to indicate that is the preferred
>> usage, or maybe make that the only guaranteed usage, and say the results
>> are undefined if you call it before calling PQgetResult. That usage also
>> makes it consistent with PQgetLastQuery being called immediately after
>> PQsendQuery.
>>
> I changed my second example to call PQgetFirstQuery after PQgetResult instead
> of before, and that removes the need to call PQconsumeInput and PQisBusy when
> you don't mind blocking. It makes the example super simple:
>
> PQsendQuery(conn, "INSERT INTO test(id) VALUES (DEFAULT),(DEFAULT)
> RETURNING id");
> query1 = PQgetLastQuery(conn);
>
> /* Duplicate primary key error */
> PQsendQuery(conn, "UPDATE test SET id=2 WHERE id=1");
> query2 = PQgetLastQuery(conn);
>
> PQsendQuery(conn, "SELECT * FROM test");
> query3 = PQgetLastQuery(conn);
>
> while( (result = PQgetResult(conn)) != NULL )
> {
> curQuery = PQgetFirstQuery(conn);
>
> if (curQuery == query1)
> checkResult(conn,result,curQuery,PGRES_TUPLES_OK);
> if (curQuery == query2)
> checkResult(conn,result,curQuery,PGRES_FATAL_ERROR);
> if (curQuery == query3)
> checkResult(conn,result,curQuery,PGRES_TUPLES_OK);
> }
>
> Note that the curQuery == queryX check will work no matter how many results a
> query produces.
Oh, that's what the PQgetLastQuery/PQgetNextQuery functions work! I
didn't understand that before. I'd suggest renaming them to something
like PQgetSentQuery() and PQgetResultQuery(). The first/last/next names
made me think that they're used to iterate a list of queries, but in
fact they're supposed to be used at very different stages.
- Heikki
--
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: hlinnakangas@vmware.com, newellm@blur.com
Subject: Re: libpq pipelining
In-Reply-To: <5481876E.3000701@vmware.com>
* 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