On Thu, Aug 5, 2010 at 7:25 AM, Simon Riggs <simon@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
especiallyglaring.
(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