Re: Deprecating RULES - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Deprecating RULES
Date
Msg-id 11878.1350516341@sss.pgh.pa.us
Whole thread Raw
In response to Re: Deprecating RULES  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Deprecating RULES  (Andrew Dunstan <andrew@dunslane.net>)
Re: Deprecating RULES  (Steve Crawford <scrawford@pinpointresearch.com>)
Re: Deprecating RULES  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> I would tend to say "well, they're not hurting anyone, why not keep
> them?" Except that we're gathering an increasing number of features
> (RETURNING, FDWs, CTEs, Command triggers) which don't work well together
> with RULEs.

Really?  On what do you base that claim?  The only one of those that I
might believe is command triggers, but AFAIK we only have/plan command
triggers for DDL, so there's no overlap.

I'm fairly annoyed by the entire tenor of this conversation, because
the people who are hollering the loudest seem to be people who have
never actually touched any of the rules code, but nonetheless seem
prepared to tell those of us who have what to spend our time on.

Now having said that, I would definitely like to see rules in their
current form go away eventually.  But not without a substitute.
Triggers are not a complete replacement, and no amount of wishful
thinking makes them so.

Perhaps it would be more profitable to try to identify the pain points
that make people so eager to get rid of rules, and then see if we could
alleviate them.  One big problem I know about offhand is the
multiple-evaluation risk, which seems at least in principle fixable.
What others are there?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: Deprecating RULES
Next
From: Tom Lane
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY