On Mon, Oct 22, 2012 at 8:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> The problems with MERGE are mostly around concurrency, as far as I can
>> tell. I can't see why RULEs would have anything to do with it -
>> except that I don't see how MERGE can sanely support rules, and even
>> if we find a way to make it do that, anyone already using RULEs will
>> need to adjust them to support MERGE. I'm not sure I have a horribly
>> well-thought-out position on the underlying issue here - I'm kind of
>> vacillating back and forth - but I do think one of the problems with
>> RULEs is that they are too tied to particular command names. Adding
>> any new commands that can select or modify data - be it MERGE, UPSERT,
>> or whatever - is going to cause trouble both for implementors and for
>> people relying on the feature.
>
> And triggers (or anything else) would be better on that score because ...?
Well, my thought was that a trigger - at least a row-level trigger -
can presumably be fired on the basis of whether an individual row is
being insert or updated, rather than on whether the statement is named
INSERT or UPDATE. If that's not correct, we've got some
head-scratching to do...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
