On Sun, Oct 24, 2010 at 2:39 PM, Greg Smith <g...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
