On 10/12/2012 08:48 PM, Greg Stark wrote:
> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs <simon@2ndquadrant.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