On Thu, Aug 5, 2010 at 7:25 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Also had these fragments as well, if they're still useful. Probably just > useful as pointers as to what else to change to include the docs. > > > The tests and docs were written from SQL standard, so any deviations > would need to be flagged. The idea of writing the tests first was that > they provide an objective test of whether the implementation works > according to spec. > > I'd quite like a commentary on anything that needs changing. Not saying > I will necessarily object to differences, but knowing the differences > sounds important for us.
I think this is a wonderful feature. A couple of thoughts: *) Would however very much like to see RETURNING support if it's not there. Our other DML statements support it, and this one should too. wCTE if/when we get it will make the lack of it especially glaring. (OTOH, no issue if there is no rule support...they should be deprecated) *) The decision to stay on the standard and not do a 'race free' version was IMO a good one. I am starting to come around to the point of view that the *only* safe way to guarantee race free merge with the current locking model is to take an appropriate table lock. BTW, our pl/pgsql upsert example we've been encouraging people to use has a horrible bug (see: http://postgresql.1045698.n5.nabble.com/Danger-of-idiomatic-plpgsql-loop-for-merging-data-td2257700.html). If we want to rework the locking model to support anticipatory locks then fine (but that has nothing to do with MERGE specifically). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
