Horton

Re: Command Triggers, patch v11

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>
Date: 2012-03-19T17:06:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.

  2. Remove useless const qualifier

  3. Make executor's SELECT INTO code save and restore original tuple receiver.

On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
>> If we were going to change the output at all, I would vote for "CREATE
>> TABLE nnnn" so as to preserve the rowcount functionality.  Keep in
>> mind though that this would force client-side changes, for instance in
>> libpq's PQcmdTuples().  Fixing that one routine isn't so painful, but
>> what of other client-side libraries, not to mention applications?
>
> Doesn't seem worth it to me.  At least, "SELECT nnnn" makes some sense:
> nnnn rows were selected.  "CREATE TABLE nnnn" means what?  nnnn tables
> were created?
>
> What might make sense is to delegate this additional information to
> separate fields in a future protocol revision.

I think that we would not have bothered to add the row count to the
command tag output for SELECT unless it were useful.  It seems to be
*more* useful for CTAS than for SELECT; after all, SELECT also returns
the actual rows.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company