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.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
