From: Matt Newell <newellm@blur.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: libpq pipelining
Date: Thu, 04 Dec 2014 16:30:19 -0800
Message-ID: <2193114.W6sD3Nzkqp@obsidian>
User-Agent: KMail/4.14.2 (Linux/3.14-2-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <5812260.A9DG1YyGp2@obsidian>
References: <2059418.jZQvL3lH90@obsidian> <5480D476.2090306@vmware.com>
 <5812260.A9DG1YyGp2@obsidian>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> 
> > 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.

Matt Newell


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers