Re: INS/UPD/DEL RETURNING for 8.2
От | Tom Lane |
---|---|
Тема | Re: INS/UPD/DEL RETURNING for 8.2 |
Дата | |
Msg-id | 16614.1141348861@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: INS/UPD/DEL RETURNING for 8.2 (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: INS/UPD/DEL RETURNING for 8.2
Re: INS/UPD/DEL RETURNING for 8.2 |
Список | pgsql-patches |
Neil Conway <neilc@samurai.com> writes: > I wonder if we should try to consistently treat an INSERT/UPDATE/DELETE > with a RETURNING clause like a SELECT with an equivalent target list. > For example, should it be possible to write: > FOR x in DELETE FROM t1 WHERE ... RETURNING t1.x LOOP Seems like you'd want to get there eventually, if not in the first cut. This might tie into something that was bothering me about Jonah's first-cut patch, which was that he was introducing special cases into places where it didn't seem real appropriate (like printtup.c). I wonder if we should rejigger the representation of Query so that a FOO-RETURNING command actually *is* a SELECT in some sense, so that there's no need for special cases. I'm a bit fuzzy about how this would work exactly --- you still need to keep track of two targetlists it seems --- but it's worth thinking about. I've had a bee in my bonnet for literally years about the fact that INSERT/SELECT really needs two levels of targetlist, as does UNION. Maybe if we thought a little bit larger we could clean up all of that messiness at one stroke. BTW, looking at the patch's test output reminds me that the appearance of a resultset causes psql to suppress showing the command status. I think this is reasonable and expected for SELECT, but I wonder whether we shouldn't force it to appear when it's something else. regards, tom lane
В списке pgsql-patches по дате отправления: