On Mon, Dec 28, 2009 at 12:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Boszormenyi Zoltan <z...@cybertec.at> writes: >> attached is a small patch that makes it possible for clients >> to receive row count for SELECT ... INTO ... and CREATE TABLE ... AS ... > >> Comments? > > This doesn't look tremendously well thought out to me. > > 1. As given, the patch changes the result not only for SELECT INTO but > for any SELECT executed in PORTAL_MULTI_QUERY context (consider SELECTs > added by rules for example). It seems like a pretty bad idea for the > result of a statement to depend on context. > > 2. In the past we have regretted it when we made the same command tag > sometimes have numbers attached and sometimes not (note the hack at > the bottom of PortalRunMulti). It doesn't seem like terribly good > design to do that here. On the other hand, always attaching a count > to SELECT tags would greatly increase the risk of breaking clients. > > > I'm not at all convinced that this is so useful as to justify taking > any compatibility risks for. People who really need that count can > get it easily enough by breaking the command into a CREATE followed > by INSERT/SELECT.
I don't know whether or not it's a good idea to do this for anything in a PORTAL_MULTI_QUERY context, because I haven't really thought through the issues. But, it's hard for me to imagine that anyone is depending on the command tag returned by CTAS or SELECT INTO. Generally, I think making command tags return more useful information is a good thing. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers