On Wed, Sep 28, 2011 at 10:53 AM, Rob Sargent <robjsargent@gmail.com> wrote:
>
>
> On 09/28/2011 08:34 AM, Tom Lane wrote:
>> Andrew Sullivan <ajs@crankycanuck.ca> writes:
>>> On Wed, Sep 28, 2011 at 06:20:04AM -0700, David Fetter wrote:
>>>> There's an even better reason not to use rules: they're going away in
>>>> a not too distant version of PostgreSQL.
>>> Really? How? I thought views were done using rules under the hood?
>>> Also, it'd be awfully nice if, in case rules are going away, the
>>> documentation actually said prominently in the rules section, "Rules
>>> are deprecated and are planned to be removed at some point in the
>>> future." Right now, anyone coming to Postgres for the first time
>>> could easily understand the manual to say that Postgres has this cool
>>> feature on which they can rely.
>> I think the true state of affairs is this: rules have a lot of
>> surprising behaviors, and if we could think of something that works more
>> straightforwardly, we'd love to replace them. But I think we'd have to
>> have the "something" in place before we consider deprecating rules.
>> At the moment we don't even have a glimmer of a design, so David's
>> statement is many years premature.
>>
>> regards, tom lane
>>
> Yoda: "Damned by faint praise, these rules are"
>
> Would this future something more likely be a totally different concept
> or a re-implementation?
>
> Is there a list of "gotchas" w.r.t. rules?
yes, and it is huge -- see the archives. note that views are based on
rules (SELECT rules) and there is nothing wrong there -- so it's not
quite correct to say they will be going away completely.
view triggers removed the #1 thing that most people wanted to do with
rules, namely updatable views. the basic problem with rules is that
by hacking the sql you send to the server, you lose control over
various aspects of the statement that normally are fairly predictable.
they are almost impossible to get working properly -- I've tried many
times. aside from the multiple evaluation thing, you have bizarre
interactions with many sql features that came in later (like
RETURNING).
folks, don't use RULES! use triggers -- and as much as possible, keep
triggers simple, short, and to the point (simple validation, custom
RI, auditing/logging, etc).
merlin
