On Wed, Oct 17, 2012 at 7:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
Well, it'd be nice to be able to rewrite a query referring to a table
to still refer to that same table, but you can't, because you get
infinite recursion.
If you could do that, it'd presumably be a WHOLE lot faster than
triggers. Because frankly, if triggers were infinitely fast, I don't
think we'd be having this conversation. But they're not. They're
slow; really slow, and while we may be able to improve that somewhat
by some means, they're basically always going to be slow. Being able
to rewrite queries is inside the server is useful, and rules are not a
very good solution to that problem, but right now they're the only
thing we've got.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
