From: | "Klaus P(dot) Pieper" <kpi6288(at)gmail(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | ON CONFLICT DO for UPDATE statements |
Date: | 2016-05-12 18:29:58 |
Message-ID: | 001201d1ac7c$4a8afd40$dfa0f7c0$@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
We run two separate databases which are synchronized through our own
replication system (two master databases, so we use our own trigger based
methods). Let's call the two databases "main" and "remote".
From time to time we get constraint violations on sorting fields classified
UNIQUE when users add records belonging the same data entity:
Create table orderpos (
int id not null primary key,
int order not null, -- the entity
int sort not null, -- sorting criteria for reporting purposes
text data,
UNIQUE (order, sort) );
I know that with PostgreSQL 9.5 I can use UPSERT to modify the field "sort"
when adding it to the remote database. I simply change the content of the
field sort to MAX(sort)+1 for this order. This will resolve the issue on the
remote side.
However, the modified value will be replicated back to the main database
where the record was generated. My concern is that in the meantime someone
might have added another order position to the master database and the value
coming back from the remote database is no longer UNIQUE.
Is there a similar concept like UPSERT for UPDATE statements? I.e.
UPDATE orderpos SET sort = 2
WHERE if = 4
ON CONFLICT sort DO UPDATE SET sort = GetSafeSortValue(2)
If not, what is the best way of avoiding a constraint violation in UPDATE
statements?
- A BEFORE UPDATE trigger checking the UNIQUE condition and calling
GetSafeSort() in case of a conflict?
- A rule?
- Can triggers be used to catch constraint violations?
My least preferred solution would by the replication software handling an
exception.
Thanks
Klaus
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2016-05-12 20:02:33 | Re: Update or Delete causes canceling of long running slave queries |
Previous Message | Klaus P. Pieper - ibeq GmbH | 2016-05-12 18:22:05 | ON CONFLICT DO for UPDATE statements |