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
