> On Jan 11, 2024, at 12:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Russell, John" <johrss@amazon.com> writes:
>> Hi, I was thinking of suggesting some doc clarifications and additional examples related to the RETURNING clause.
Justa couple of questions first to see if my understanding is correct.
>
>> I was trying to figure out what the precise “thing” is that comes back from a RETURNING clause. A table reference? A
resultset?
>
> I'd say it's a result set, just like the output of SELECT.
>
>> That made me think both a RETURNING clause could work in contexts such as CTE (yes) and subquery (seems like no).
>
> We disallow DML in subqueries because there's a lot of squishiness
> around when a subquery is evaluated, whether it's evaluated to
> completion, or indeed whether it's evaluated more than once.
> CTEs have tighter semantics and so it's practical to require
> "exactly once" evaluation for CTEs. Partly this is a matter of
> historical expectations, but I doubt we'd consider revisiting it.
Makes sense. I don’t mind the limitation, I was just thinking of places to document it and examples to add to
illustrateusage of RETURNING. If you want to rename columns in the result set, use AS clauses for the column names in
RETURNING.If you want to sort and filter what comes back from RETURNING, use a CTE and select from that. My first idea
wasto try a subquery for all such cases; hadn’t thought of how subqueries might get pruned, moved around, or repeated.
>>> PostgreSQL allows INSERT, UPDATE, and DELETE to be used as WITH queries. This is not found in the SQL standard.
>
>> Is MERGE allowed in that ^^^ context?
>
> Not yet, as you'd find out if you tried it. I think there's a patch
> in the pipeline to allow it.
On the way to trying it, I did see in the doc that MERGE doesn’t have a RETURNING clause, which I presume makes the
pointmoot. If there’s a patch that adds such support in process, I won’t suggest adding “MERGE not supported” at this
spotin the doc.
Thanks,
John
