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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-12-28 16:31:13 Re: Removing pg_migrator limitations
Previous Message Simon Riggs 2009-12-28 16:14:12 Re: updateMinRecoveryPoint bug?