Re: [PATCH] Provide rowcount for utility SELECTs
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Provide rowcount for utility SELECTs |
Дата | |
Msg-id | 603c8f070912290006h33339d4fmcb1cecfef2d43cbd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Provide rowcount for utility SELECTs (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Dec 28, 2009 at 12:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Boszormenyi Zoltan <zb@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
В списке pgsql-hackers по дате отправления: