On Thu, Oct 23, 2014 at 9:43 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
