Re: Deprecating RULES

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deprecating RULES
Date: 2012-10-22 12:57:31
Message-ID: 27206.1350910651@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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 ...?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-10-22 13:10:22 ToDo: KNN Search should to support DISTINCT clasuse?
Previous Message Robert Haas 2012-10-22 11:53:30 Re: Deprecating RULES