Robert Haas <robertmh...@gmail.com> writes: > On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers