public inbox for [email protected]
help / color / mirror / Atom feedFrom: David G. Johnston <[email protected]>
To: Brian McMahon <[email protected]>
Cc: [email protected]
Subject: Re: Support for on conflict ignore returning
Date: Tue, 30 Jul 2024 09:00:42 -0700
Message-ID: <CAKFQuwbJ9YdZz=UPdyoJnzCj9MkBPb7DLs+ziDAUz0Yz5YN1-Q@mail.gmail.com> (raw)
In-Reply-To: <CA+0iD35fvs6cXybmj+FSY_QWpir_c60gGzoi+GX+jTLHEf0Z-A@mail.gmail.com>
References: <CA+0iD35fvs6cXybmj+FSY_QWpir_c60gGzoi+GX+jTLHEf0Z-A@mail.gmail.com>
On Tue, Jul 30, 2024 at 8:54 AM Brian McMahon <[email protected]>
wrote:
>
> Is there a recommended way to achieve a ON CONFLICT DO NOTHING RETURNING
> <column> so that conflicting columns still have information returned?
> Currently it seems like the only simple way to achieve this is with a NOOP
> update, so instead doing something like ON CONFLICT UPDATE SET name =
> EXCLUDED.name RETURNING <column>.
>
This is requested frequently. As of now I'm not aware of anyone working on
a patch to make it work.
For the described "chained DML" use case my typical advice is to not rely
upon the "default" clause to produce your surrogate keys but to produce
them yourself. Also, this is one of the few areas that iterating
row-by-row and doing one set of multi-table DML per transaction (or maybe
savepoint...) works out reasonably well.
David J.
view thread (3+ messages) latest in thread
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: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Support for on conflict ignore returning
In-Reply-To: <CAKFQuwbJ9YdZz=UPdyoJnzCj9MkBPb7DLs+ziDAUz0Yz5YN1-Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox