| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Brian McMahon <brianmcmahon135(at)gmail(dot)com> |
| Cc: | pgsql-novice(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Support for on conflict ignore returning |
| Date: | 2024-07-30 16:00:42 |
| Message-ID: | CAKFQuwbJ9YdZz=UPdyoJnzCj9MkBPb7DLs+ziDAUz0Yz5YN1-Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
On Tue, Jul 30, 2024 at 8:54 AM Brian McMahon <brianmcmahon135(at)gmail(dot)com>
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brian McMahon | 2024-07-30 16:37:14 | Re: Support for on conflict ignore returning |
| Previous Message | Brian McMahon | 2024-07-30 15:53:55 | Support for on conflict ignore returning |