Re: Deprecating RULES

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deprecating RULES
Date: 2012-10-18 20:55:02
Message-ID: 50806CA6.1080702@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/18/2012 01:11 PM, Daniel Farina wrote:

> Here's another use case that in my history with RULES that didn't seem
> to pan out so well: In my recollection, one way to use rules is to
> retarget operations that happen against a view and move them to a
> table, and as I recall to make this work as one expected one had to
> have a very wordy RULE (for UPDATEs) with a litany of (fairly simple)
> equality and not-null conditions to make it work as one would expect
> (to not under-constrain the UPDATE). This became a maintenance
> headache whenever attributes were added to the underlying relation.

Yes, but you also get a similar headache with a trigger. Unless you're
VERY careful you can get a trigger failure by adding an attribute, and
an almost guaranteed one by removing an attribute. It's true that the
language for specifying the operations is more expressive, but no matter
what mechanism you use, changing the shape of the objects can get you
into trouble.

I've never said that rules are perfect, nor that they should be used
whenever possible. What I have said is that there are known cases where
they are the best solution currently available. I still think that.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-10-18 20:56:07 Re: embedded list
Previous Message Boszormenyi Zoltan 2012-10-18 20:40:15 Re: [PATCH] lock_timeout and common SIGALRM framework