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

On Thu, Oct 23, 2014 at 9:43 PM, Peter Geoghegan <pg@heroku.com> wrote:
> * CONFLICTING() is renamed to EXCLUDED(). I know that some people
> wanted me to go a different way with this. I think that there are very
> good practical reasons not to [1], as well as good reasons related to
> design, but I still accept that CONFLICTING() isn't very descriptive.
> This spelling seems a lot better.

Specifically, "some people" included at least three committers and at
least one other community member no less prominent than yourself, or
in other words, every single person who bothered to comment.  You can
think whatever you like; the chances of it being committed that way
are zero.

> 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.

As far as syntax goes, I thought the INSERT .. ON CONFLICT UPDATE
syntax proposed upthread was the best of any mentioned thus far.  The
MERGE-based syntaxes proposed upthread were crazily verbose for no
discernable benefit.

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.

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