On Thu, Feb 8, 2018 at 8:23 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> Some novel new behavior -- "EPQ with a twist"-- is clearly necessary.
> I feel a bit uneasy about it because anything that anybody suggests is
> likely to be at least a bit arbitrary (EPQ itself is kind of
> arbitrary). We only get to make a decision on how "EPQ with a twist"
> will work once, and that should be a decision that is made following
> careful deliberation. Ambiguity is much more likely to kill a patch
> than a specific technical defect, at least in my experience. Somebody
> can usually just fix a technical defect.
Here's my $0.02: I think that new concurrency errors thrown by the
merge code itself deserve strict scrutiny and can survive only if they
have a compelling justification, but if the merge code happens to
choose an action that leads to a concurrency error of its own, I think
that deserves only mild scrutiny.
On that basis, of the options I listed in
http://postgr.es/m/CA+TgmoZDL-caukHkWet7sr7sqr0-e2T91+DEvhqeN5sfqsMjqw@mail.gmail.com
I like #1 least.
I also dislike #4 from that list for the reasons stated there. For
example, if you say WHEN MATCHED AND x.some_boolean and then WHEN
MATCHED, you expect that every tuple that hits the latter clause will
have that Boolean as false or null, but #4 makes that not true.
I think the best options are #2 and #5 -- #2 because it's simple, and
#5 because it's (maybe) more intuitive, albeit at the risk of
livelock. But I'm willing to convinced of some other option; like
you, I'm willing to be open-minded about this. But, as you say, we
need a coherent, well-considered justification for the selected
option, not just "well, this is what we implemented so you should like
it". The specification should define the implementation, not the
reverse.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company