Re: ask for review of MERGE - Mailing list pgsql-hackers

From Greg Stark
Subject Re: ask for review of MERGE
Date
Msg-id AANLkTi=kmFsD5zdN6FFwXv-i6zPcj=o8SK1Vq07kz+5Z@mail.gmail.com
Whole thread Raw
In response to Re: ask for review of MERGE  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
On Sun, Oct 24, 2010 at 2:39 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Sure, but in the most common use case I think we're targeting at first, no
> indexes means there's also no unique constraints either.  I don't think
> people can reasonable expect to MERGE or anything else to guarantee they
> won't accidentally create two rows that conflict via the terms of some
> non-database enforced key.

I'm fine with either a) having the merge constraint be required to
match exactly either a exclusion constraint or unique index or throw
an error or b) lock the table if you perform a merge against a table
on a non-indexed condition like foreign keys do if you're missing the
relevant index.

Either way I expect this case to be a rare use case where users are
either doing data loads and locking the table against concurrent
updates is fine or they will immediately realize the error of their
ways and create the corresponding unique or exclusion constraint
index.

Other than bulk data loads I don't see any useful use case that
doesn't have the corresponding exclusion constraint or unique index as
a hard requirement anyways. It'll be necessary for both correctness
and performance.

--
greg


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: ask for review of MERGE
Next
From: "Kevin Grittner"
Date:
Subject: Re: Serializable snapshot isolation patch