Jeff Davis:
To summarize, most of the problem has been in retrieving the action
(INSERT/UPDATE/DELETE) taken or the WHEN-clause number applied to a
particular matched row. The reason this is important is because the row
returned is the old row for a DELETE action, and the new row for an
INSERT or UPDATE action. Without a way to distinguish the particular
action, the RETURNING clause returns a mixture of old and new rows,
which would be hard to use sensibly.
It seems to me that all of this is only a problem, because there is only
one RETURNING clause.
Dean Rasheed wrote in the very first post to this thread:
I considered allowing a separate RETURNING list at the end of each
action, but rapidly dismissed that idea. Firstly, it introduces
shift/reduce conflicts to the grammar. These can be resolved by making
the "AS" before column aliases non-optional, but that's pretty ugly,
and there may be a better way. More serious drawbacks are that this
syntax is much more cumbersome for the end user, having to repeat the
RETURNING clause several times, and the implementation is likely to be
pretty complex, so I didn't pursue it.
I can't judge the grammar and complexity issues, but as a potential user
it seems to me to be less complex to have multiple RETURNING clauses,
where I could inject my own constants about the specific actions, than
to have to deal with any of the suggested functions / clauses. More
repetitive, yes - but not more complex.
More importantly, I could add RETURNING to only some of the actions and
not always all at the same time - which seems pretty useful to me.
Best,
Wolfgang
