Horton

Re: Command Triggers, patch v11

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>
Date: 2012-03-19T01:16:26Z
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.

Peter Eisentraut <peter_e@gmx.net> writes:
> On lr, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
>> I'm not sure what we should do instead.  We have gotten push-back before
>> anytime we changed the command tag for an existing command (and in fact
>> it seems that we intentionally added the rowcount display in 9.0, which
>> means there are people out there who care about that functionality).
>> On the other hand, the traditional output for CREATE TABLE AS doesn't
>> seem to satisfy the principle of least astonishment.  A third
>> consideration is that if we are pushing CREATE TABLE AS as the preferred
>> spelling, people will probably complain if it omits functionality that
>> SELECT INTO provides; so I'm not sure that "SELECT n" in one case and
>> "CREATE TABLE AS" in the other would be a good idea either.  Any
>> opinions what to do here? 

> Another consideration is that the SQL command tags are defined by the
> SQL standard.  So if we were to change it, then it should be "CREATE
> TABLE".  I'm not convinced that it should be changed, though.  (I recall
> cross-checking our list against the SQL standard in the past, so there
> might have been discussion on this already.)

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?

			regards, tom lane