From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Thom Brown <thom(at)linux(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Subject: | Re: Command Triggers, patch v11 |
Date: | 2012-03-19 01:16:26 |
Message-ID: | 24506.1332119786@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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-19 01:50:34 | Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
Previous Message | Tom Lane | 2012-03-19 01:11:06 | Re: Command Triggers, patch v11 |