pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Russell, John <johrss@amazon.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
Subject: Re: Question on doc for RETURNING clause
Date: Thu, 11 Jan 2024 21:11:49 +0000
Message-ID: <F5C61787-5D95-4119-9C38-DE62256CECB4@amazon.com> (raw)
In-Reply-To: <317971.1705005831@sss.pgh.pa.us>
References: <9A518B72-829E-4133-B193-0E168D47723E@amazon.com>
	<317971.1705005831@sss.pgh.pa.us>



> 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. 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

view thread (4+ messages)

Message-ID: <F5C61787-5D95-4119-9C38-DE62256CECB4@amazon.com>
Permalink:  ../F5C61787-5D95-4119-9C38-DE62256CECB4@amazon.com/
Also on:    postgresql.org/message-id/F5C61787-5D95-4119-9C38-DE62256CECB4@amazon.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-docs@postgresql.org
  Cc: johrss@amazon.com, tgl@sss.pgh.pa.us, pgsql-docs@lists.postgresql.org
  Subject: Re: Question on doc for RETURNING clause
  In-Reply-To: <F5C61787-5D95-4119-9C38-DE62256CECB4@amazon.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox