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