> On Jan 11, 2024, at 12:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > "Russell, John" <joh...@amazon.com> writes: >> Hi, I was thinking of suggesting some doc clarifications and additional >> examples related to the RETURNING clause. Just a 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 result set? > > 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 illustrate usage 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 was to 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 point moot. If there’s a patch that adds such support in process, I won’t suggest adding “MERGE not supported” at this spot in the doc. Thanks, John
