On Tue, Sep 30, 2014 at 8:30 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 29 September 2014 18:59, Peter Geoghegan <pg@heroku.com> wrote:
>> On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> If you were an ORM developer reading the PostgreSQL Release Notes for
>>> 9.5, which URL would you visit to see a complete description of the
>>> new feature, including how it works concurrently, locking and other
>>> aspects. How would you check whether some strange behaviour was a bug,
>>> or intentional?
>>
>> We don't do that with UPDATE, so why would we do it with this?
>
> Because this is new, harder and non-standard, so there is no other
> place to look. If you want to persuade us that MERGE has poorly
> defined concurrency, so you have implemented a new command, the new
> command had better have very well defined behaviour.
I'm making a point about the structure of the docs here. The behavior
*is* documented, just not in the INSERT documentation, a situation
I've compare with how EvalPlanQual() isn't discussed in the
UPDATE/DELETE/SELECT FOR UPDATE docs. And EvalPlanQual() has some
pretty surprising corner-case behaviors.
That having been said, maybe I could have gone into more detail on the
"consensus among unique indexes" thing in another part of the
documentation, since that isn't separately covered (only the aspects
of when the predicate is evaluated in READ COMMITTED mode and other
things like that were covered).
> For example, this patch for UPSERT doesn't support updatable views.
> But I can't see anyone that didn't read the patch would know that.
By reading the CREATE VIEW docs. Maybe there could stand to be a
compatibility note in the main INSERT command, but I didn't want to do
that as long as things were up in the air. It might be the case that
we figure out good behavior for updatable views.
--
Peter Geoghegan