Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Fri, Oct 24, 2014 at 3:01 PM, Peter Geoghegan <pg@heroku.com> wrote:
> This is the situation with unique index inference all over again. You
> don't like a function-like expression. Okay. It would be a lot more
> helpful if instead of just criticizing, you *also* looked at my
> reasons for not wanting to go with something that would necessitate
> adding a dummy range table entry [1].

The problem here isn't that I haven't read your emails.  I have read
them all, including that one.  Moreover, this isn't the first time
you've asserted that someone hasn't read one of your emails.  So if
we're going to say what we each think would be helpful, then I think
it would be helpful if you stopped accusing the people who are taking
time to provide feedback on your work of having failed to read your
emails.  It's possible that there may be instances where that problem
exists, but it beggars credulity to suppose that the repeated
unanimous consensus against some of your design decisions is entirely
an artifact of failure to pay attention.

The fact is, I don't feel obliged to respond to every one of your
emails, just as you don't respond to every one of mine.  If you want
this patch to ever get committed, it's your job to push it forward -
not mine, not Simon's, and not Heikki's.  Sometimes that means you
have to solve hard problems instead of just articulating what they
are.

> There are some very good
> practical reasons for avoiding that. We only do that (the OLD.* and
> NEW.* stuff) in the context of CREATE RULE and one or two other
> things. We don't play any games like that during parse analysis of
> ordinary optimizable statements, which is what this is. And those
> dummy RTEs are always placeholders, AFAICT. Apart from those technical
> reasons, the two situations just aren't comparable from a user-visible
> perspective, but that isn't the main problem.
>
> I don't particularly expect you to come around to my view here. But it
> would be nice to have the problems with dummy RTEs and so on
> acknowledged, so it's understood that that is in itself a strange new
> direction for parse analysis of ordinary optimizable statements.

You're conflating the user-visible syntax with the parse tree
representation in way that is utterly without foundation.  I don't
have a position at this point on which parse-analysis representation
is preferable, but it's completely wrong-headed to say that you
"can't" make NEW.x produce the same parse-analysis output that your
CONFLICTING(x) syntax would have created.  Sure, it might be harder,
but it's not that much harder, and it's definitely not an unsolvable
problem.

I do acknowledge that there might be a better syntax out there than
NEW.x and OLD.x.  I have not seen one proposed that I like better.
Feel free to propose something.  But don't keep re-proposing something
that LOOKSLIKE(this) because nobody - other than perhaps you - likes
that.  And don't use the difficulty of parse analysis as a
justification for your proposed syntax, because, except in extreme
cases, there are going to be very few if any regular contributors to
this mailing list who will accept that as a justification for one
syntax over another.  Syntax needs to be justified by being beautiful,
elegant, precedent-driven, orthogonal, and minimalist - not by whether
you might need an extra 25-75 lines of parse analysis code to make it
work.

>>> Unique index inference (i.e. the way we figure out  *which* unique
>>> index to use) occurs during parse analysis. I think it would be
>>> inappropriate, and certainly inconvenient to do it during planning.
>>
>> You're wrong.  The choice of which index to use is clearly wildly
>> inappropriately placed in the parse analysis phase, and if you think
>> that has any chance of ever being committed by anyone, then you are
>> presuming the existence of a committer who won't mind ignoring the
>> almost-immediate revert request that would draw from, at the very
>> least, Tom.
>
> Why? This has nothing to do with optimization.

That is false.  If there is more than one index that could be used,
the system should select the best one.  That is an optimization
decision per se.  Also, if a plan is saved - in the plancache, say, or
in a view - the query can be re-planned if the index it depends on is
dropped, but there's no way to do parse analysis.

>> As much as I'd like to have this feature, your refusal to change
>> anything except when asked at least three times each by about five
>> different people makes this effort barely worth pursuing.  You can say
>> all you like that you're receptive to feedback, but multiple people
>> here are telling you that they feel otherwise.
>
> I'm tired of your assertions about why I haven't done certain things.
> It's not fair. I have incorporated a lot of feedback into V1.3 (and
> previous versions), which isn't acknowledged. Also, I moved to the USA
> this week, and things have been hectic. As I said in relation to
> unique index inference, please consider that I haven't immediately
> complied with that feedback because there are genuine technical
> obstacles that at the very least make it more difficult than it
> appears. And, I'm not necessarily able to comply quickly because of
> time constraints.

Well, I'm equally tired of being asked to review patches that respond
to only a small percentage of the feedback already given.  I, too,
sometimes lack the time to incorporate the feedback of others into my
patches.  When that happens, I don't re-post them until I do have the
time.  I've even been known to drop patches altogether rather than
continue arguing about them, as you will of course recall.  There's no
shame in taking longer to get something done, but asking other people
to spend time on it when you haven't had time yourself can lead to
frustrations.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company