Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> 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.
I think we're all in agreement that we need to keep the rowcount
functionality. What seems to me to be in some doubt is whether to
continue to present the tag "SELECT nnnn" or to change it to something
like "CREATE TABLE nnnn". For the moment I've got the patch doing the
former. It would not be terribly hard to change it, but I'm not going
to break backward compatibility unless there's a pretty clear consensus
to do so.
BTW, I just came across another marginal-loss-of-functionality issue:
in previous versions you could PREPARE a SELECT INTO, but now you get
regression=# prepare foo as select * into bar from int8_tbl;
ERROR: utility statements cannot be prepared
Is anybody excited about that? If it is something we have to keep,
it seems like pretty nearly a deal-breaker for this patch, because
storing a CreateTableAsStmt containing an already-prepared plan would
complicate matters unreasonably. You can still get approximately
the same result with
prepare foo as select * from int8_tbl;create table bar as execute foo;
which if anything is more useful since you didn't nail down the target
table name in the PREPARE, but nonetheless it's different.
regards, tom lane
