Re: [GENERAL] UPDATE ... ON CONFLICT DO NOTHING

You need to remove the "might" and figure out which ones will and which will not.  You can update the ones will not and delete the ones that do.

Free-thinking:

WITH figure_things_outs AS (

-- not exactly sure how this looks but I would probably try to construct the new relation with the updates in place

-- and use something like row_number() OVER (PARTITION BY uid, author ORDER BY pk) to detect future duplicates

),

delete_these AS (

DELETE FROM tbl

USING figure_things_out

WHERE tbl.pk = figure_things_out.pk

AND figure_things_out.row_number > 1

)​,

and_update_the_rest AS (

UPDATE tbl

WHERE EXISTS ( ... WHERE row_number = 1 )

-- consider using a trigger here to avoid writing no-op updates to disc

)

SELECT * FROM delete_these

UNION ALL

SELECT * FROM and_update_the_rest

;

I'd suggest you find some way to abstract away the table name and columns so you can write the logic once and specify the table name and columns as part of the input.

OR

WITH going_away_author_change AS (

DELETE FROM tbl

RETURNING uid, author

),

WITH going_away_user_change AS (

)

INSERT INTO tbl

SELECT uid, new_author FROM going_away_author_change

UNION ALL

SELECT new_uid, author FROM going_away_user_change

ON CONFLICT DO NOTHING -- haven't used personally, you should get the idea though

OR

WITH nuclear_option AS (

DELETE FROM tbl

RETURNING *

), make_new_records AS (

SELECT DISTINCT ON (uid, author) uid, author, ... -- ensure this outputs records meeting your PK constraint

FROM nuclear_option -- sprinkle renaming logic where needed

ORDER BY uid, author, pk

)

INSERT INTO tbl

SELECT * FROM make_new_records;

David J.