Robert Haas wrote:
> And even if it isn't, the MERGE syntax is insane if what you really
> want to do is insert or update ONE record. If all we have is MERGE,
> people will keep doing it with a PL/pgsql stored procedure or some
> crummy application logic just so that they don't have to spend several
> days trying to understand the syntax. Heck, I understand the syntax
> (or I think I do) and I still think it's more trouble than its worth
I hoped that the manual would have a clear example of "this is how you
do UPSERT with MERGE", preferrably cross-linked to the existing "Example
39-2. Exceptions with UPDATE/INSERT" trigger implementation that's been
the reference implementation for this for a long time, so people can see
both alternatives. New users will cut and paste that example into their
code, and in the beginning neither know nor care how MERGE actually
works, so long as the example does what it claims. I would wager the
majority of PL/pgsql implementations of this requirement start the exact
same way. I don't think the learning curve there is really smaller,
it's just that you've just already been through it.
I've been purposefully ignoring the larger applications of MERGE in the
interest of keeping focus on a managable subset. But the more general
feature set is in fact enormously useful for some types of data
warehouse applications. Build REPLACE, and you built REPLACE. Build
MERGE that is REPLACE now and eventually full high-performance MERGE,
and you've done something with a much brighter future. I don't think
the concurrency hurdles here are unique to this feature either, as shown
by the regular overlap noted with the other serialization work.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
