Re: Deprecating RULES

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deprecating RULES
Date: 2012-10-12 19:29:22
Message-ID: 50786F92.1040709@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/12/2012 08:48 PM, Greg Stark wrote:
> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> AFAICS all RULEs can be re-expressed as Triggers or Views.
> This is a bizarre discussion. Firstly this isn't even close to true.
> The whole source of people's discontentment is that triggers are *not*
> equivalent to rules. If they were then they wouldn't be so upset.
>
> Secondly the only reason views work is because they're implemented
> using rules.
Nobody is discussing deprecating VIEWs.

And SELECT rules that are the basis of VIEWs are deprecated
from being an independent user-visible feature for quite some
time already
> If you want to do anything similar but different from
> views you would need to use rules as well. I'm still waiting on
> updateable views for example.
You CAN do these using triggers, that is the main reason we
have INSTEAD triggers.
> It sounds like what people are really looking for is to move the
> section of the manual describing rules to an "internals" section of
> the manual and add a note saying "do not try to use rules to implement
> triggers. they are not triggers" that explains how they're different
> and what they're useful for.
Moving them to internals _and_ adding a note to not use them
directly for any user code seems like a good plan.

And replacing the original RULES page with suggestion to look
under internals.
> In general user manuals, especially ones written like Unix man pages,
> tend to describe what things do without explaining why that might be
> useful. That's leaves users faced with a decision between trying
> similar-sounding features like rules and triggers and they might pick
> the wrong one. The Postgres manual is better than most in this respect
> but this is one area where it might pay to be extra clear.
>
-------------------
Hannu Krosing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2012-10-12 19:44:06 Re: Successor of MD5 authentication, let's use SCRAM
Previous Message Pavel Stehule 2012-10-12 19:27:46 Re: enhanced error fields