Peter, > Note also that this doesn't preclude a variant with a more direct > update part (not that I think that's all that compelling). Doing > things this way was motivated by:
I can see the value in the CTE format for this for existing PostgreSQL users. (although, AFAICT it doesn't allow for the implementation of one of my personal desires, which is UPDATE ... ON NOT FOUND INSERT, for cases where updates are expected to occur 95% of the time, but that's another topic. Unless "rejects" for an Update could be the leftover rows, but then we're getting into full MERGE.). I'm just pointing out that this doesn't do much for the MySQL migration case; the rewrite is too complex to automate. I'd been assuming that we had some plans to implement a MySQL-friendly syntax for 9.5, and this version was a stepping stone to that. Does this version make a distinction between PRIMARY KEY constraints and UNIQUE indexes? If not, how does it pick among keys? If so, what about tables with no PRIMARY KEY for various reasons (like unique GiST indexes?) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
