Re: ON CONFLICT DO SELECT (take 3) - Mailing list pgsql-hackers

From Viktor Holmberg
Subject Re: ON CONFLICT DO SELECT (take 3)
Date
Msg-id af711978-dac1-4c79-a7cd-83cdf89c0af6@Spark
Whole thread Raw
In response to Re: ON CONFLICT DO SELECT (take 3)  (jian he <jian.universality@gmail.com>)
List pgsql-hackers
On 28 Jan 2026 at 09:53 +0100, jian he <jian.universality@gmail.com>, wrote:

doc/src/sgml/ref/create_policy.sgml
<para>
When an <literal>INSERT</literal> command has an auxiliary
<literal>ON CONFLICT DO UPDATE</literal> clause, if the
<literal>UPDATE</literal> path is taken, the row to be updated is
first checked against the <literal>USING</literal> expressions of
For ON CONFLICT DO SELECT, perhaps we should add some explanatory text
to the preceding paragraph?
I think this is overkill. The previous paragraph talks about the returning clause, and in general I think the behaviour is obvious? Or did you have anything specific in mind?
typedef struct RTEPermissionInfo
comment:
* For SELECT/INSERT/UPDATE permissions, if the user doesn't have table-wide
* permissions then it is sufficient to have the permissions on all columns
* identified in selectedCols (for SELECT) and/or insertedCols and/or
* updatedCols (INSERT with ON CONFLICT DO UPDATE may have all 3).

This applies to ON CONFLICT DO SELECT FOR UPDATE, i think.
Maybe we can update this too.
I think the comment is clear enough as is - the example about ON CONFLCIT DO UPDATE is just to illustrate how it works. Adding details about DO SELECT seems out of place here? No a hill I'm willing to die on but maybe you can suggest something if you disagree Jian?
Overall, these are all the issues I’ve identified. Aside from those
issues, the patch looks very good.

--
jian
Here comes v.22 with all your comments except those 2 mentioned above updated in line with your comments Jian.
I squashed everything together - if you’d rather have the fixes as a separate commit for review let me know.
Thanks again for your detailed feedback & fixes. I’m sorry you’ve had to go though so many iterations of review on this one, but hopefully it’s starting to look ok now.

/Viktor
Attachment

pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Add SECURITY_INVOKER_VIEWS option to CREATE DATABASE
Next
From: Steve Chavez
Date:
Subject: Re: Add SECURITY_INVOKER_VIEWS option to CREATE DATABASE