On 10/01/2014 04:31 PM, Simon Riggs wrote:
On 1 October 2014 13:43, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:
That does sound interesting, but I am concerned the semantics may cause
issues.
If I go to insert a row for 'UK' and find an existing row for
'Europe', do we really want to update the population of Europe to be
the population of the UK, simply because the UK and Europe have an
exclusion conflict?
Clearly not, but you might want to insert the tuple to another table
instead, or skip it altogether. Or you might want to UPDATE Europe into
Continental Europe, and then insert the row for UK.
Not trying to catch you out, just trying to make sure we don't make
technical decisions based upon unachievable ideas.
I can't see value in having upsert work against exclusion constraint
indexes; thus this only needs to work for btrees, or similar exact
indexes.
Well, if nothing else, it would be nice to fix the concurrency issue we
have with exclusion constraints today, which is that if two backends
insert the same value at the same time, they might both get an error,
even though you'd only need to abort one of them. That's a special case
of UPSERT if you squint a little.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
