public inbox for [email protected]  

help / color / mirror / Atom feed

From: Brian McMahon <[email protected]>
To: David G. Johnston <[email protected]>
Cc: [email protected]
Subject: Re: Support for on conflict ignore returning
Date: Tue, 30 Jul 2024 09:37:14 -0700
Message-ID: <CA+0iD34KCTe6b=-ahbS=wq5EH+YSW4JARJ99QM2kqSAZkVxqUg@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwbJ9YdZz=UPdyoJnzCj9MkBPb7DLs+ziDAUz0Yz5YN1-Q@mail.gmail.com>
References: <CA+0iD35fvs6cXybmj+FSY_QWpir_c60gGzoi+GX+jTLHEf0Z-A@mail.gmail.com>
	<CAKFQuwbJ9YdZz=UPdyoJnzCj9MkBPb7DLs+ziDAUz0Yz5YN1-Q@mail.gmail.com>

Thanks for the quick response David!

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

We do use auto generated uuids, and if I understand you advice correctly
our application could generate the surrogate keys, but they would need to
be generated by some hashing algorithm of the other unique identifiers,
otherwise the application wouldn't be able to know what the surrogate key
for a row is without re-querying that database. I've tried to avoid this
just because it makes changing constraints a bit more complicated since the
keys would also change and that would need to be rectified. Please dig into
this if my response doesn't reflect what you were suggesting.

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

Just to make sure I'm understanding this correctly, would this be a single
sql statement that loops through the input data, inserts one row the
updates the other tables that need updating before moving onto the next
insert? Or is this sending multiple sql statements from the application?
Are there performance implications between looping over a data set and
inserting one by one vs doing a single insert statement with multiple rows?

Thanks in advace!

On Tue, Jul 30, 2024 at 9:01 AM David G. Johnston <
[email protected]> wrote:

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

-- 
Sincerely,
Brian McMahon

view thread (3+ messages)

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: <CA+0iD34KCTe6b=-ahbS=wq5EH+YSW4JARJ99QM2kqSAZkVxqUg@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