public inbox for [email protected]help / color / mirror / Atom feed
Support for on conflict ignore returning 3+ messages / 2 participants [nested] [flat]
* Support for on conflict ignore returning @ 2024-07-30 15:53 Brian McMahon <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Brian McMahon @ 2024-07-30 15:53 UTC (permalink / raw) To: [email protected] Hi! I have a question about support / if there's plans to support a feature, I thought it would be best to send it to the "novice" mailing list because it might be a naive question that's been answered before. 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>. As I understand it, this isn't desirable as there's various potentially undesirable side effects since it's not treated as a NOOP, it's treated as an update so triggers and all sorts of internal postgres logic are invoked (which may or may not be fine for certain applications, but it's not desirable). Are there current features that support this functionality, or plans to support something like this in the future? I should probably add my use case, I need to insert a bunch of rows into the database to ensure they exist, then for all those rows I need to update corresponding tables that reference them with more data. If I can't make a query that returns the primary key, then I either need to make a subsequent query to pull all the rows from the database that weren't inserted to get the primary keys, or I need to use the unique fields that caused the conflict in the next query to update the tables that reference the table I updated, which makes things a little messier (I'd rather just work with the primary keys when possible). Thanks in advance. -- Sincerely, Brian McMahon ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Support for on conflict ignore returning @ 2024-07-30 16:00 David G. Johnston <[email protected]> parent: Brian McMahon <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: David G. Johnston @ 2024-07-30 16:00 UTC (permalink / raw) To: Brian McMahon <[email protected]>; +Cc: [email protected] 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. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Support for on conflict ignore returning @ 2024-07-30 16:37 Brian McMahon <[email protected]> parent: David G. Johnston <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Brian McMahon @ 2024-07-30 16:37 UTC (permalink / raw) To: David G. Johnston <[email protected]>; +Cc: [email protected] 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-07-30 16:37 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-07-30 15:53 Support for on conflict ignore returning Brian McMahon <[email protected]> 2024-07-30 16:00 ` David G. Johnston <[email protected]> 2024-07-30 16:37 ` Brian McMahon <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox