Message-ID: <5481876E.3000701@vmware.com>
Date: Fri, 5 Dec 2014 12:22:38 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Matt Newell <newellm@blur.com>
CC: <pgsql-hackers@postgresql.org>
Subject: Re: libpq pipelining
References: <2059418.jZQvL3lH90@obsidian> <5480D476.2090306@vmware.com>
 <5812260.A9DG1YyGp2@obsidian> <2193114.W6sD3Nzkqp@obsidian>
In-Reply-To: <2193114.W6sD3Nzkqp@obsidian>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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