Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Provide rowcount for utility SELECTs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Provide rowcount for utility SELECTs
Date: 2009-12-28 16:20:19
Message-ID: 11409.1262017219@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On mn, 2009-12-28 at 11:08 -0500, Tom Lane wrote:
>> And, by the same token, the scope for possibly breaking clients is nearly
>> unlimited ...

> Why is that?  Are there programs out there that expect PQcmdTuples() to
> return something that is *not* the tuple count for these commands and
> will violently misbehave otherwise?

It's more the possibility of doing strcmp(tag, "SELECT") on the command
tag that worries me.  Describing the API change here as being limited
to PQcmdTuples misses the point rather completely: this is a protocol
change, and could break both clients and non-libpq driver libraries.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-12-28 16:31:13
Subject: Re: Removing pg_migrator limitations
Previous:From: Simon RiggsDate: 2009-12-28 16:14:12
Subject: Re: updateMinRecoveryPoint bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group