On 10/01/2014 04:31 PM, Simon Riggs wrote:
> On 1 October 2014 13:43, Heikki Linnakangas <hlinnakangas@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
