On 09/30/2014 07:15 AM, Kevin Grittner wrote:
> There are certainly other ways to do it, although they require more
> work. As far as UPSERT goes, I agree that we should require such
> an index, at least for the initial implementation and into the
> foreseeable future. What I'm saying is that if we implement it
> using the standard MERGE syntax, then if the features of MERGE are
> extended it will continue to work even in the absence of such an
> index. The index becomes a way of optimizing access rather than
> defining what access is allowed.
> At the risk of pushing people away from this POV, I'll point out
> that this is somewhat similar to what we do for unlogged bulk loads
> -- if all the conditions for doing it the fast way are present, we
> do it the fast way; otherwise it still works, but slower.
Except that switching between fast/slow bulk loads affects *only* the
speed of loading, not the locking rules. Having a statement silently
take a full table lock when we were expecting it to be concurrent
(because, for example, the index got rebuilt and someone forgot the
UNIQUE) violates POLA from my perspective.
PostgreSQL Experts Inc.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: