On Thu, Feb 8, 2018 at 8:23 PM, Peter Geoghegan <p...@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
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
The Enterprise PostgreSQL Company