Re: Deprecating RULES

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Andrew Dunstan
> Sent: Thursday, October 11, 2012 8:52 PM
> To: Daniel Farina
> Cc: Joshua D. Drake; Josh Berkus; Simon Riggs;
pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Deprecating RULES
>
>
> On 10/11/2012 08:20 PM, Daniel Farina wrote:
> > On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake
> <jd(at)commandprompt(dot)com> wrote:
> >> On 10/11/2012 03:59 PM, Josh Berkus wrote:
> >>
> >>> I'm also not real keen on the idea that someone could dump a 9.2
> >>> database and be unable to load it into 9.3 because of the DDL
> >>> trigger, especially if they might not encounter it until halfway
> >>> through a restore. That seems rather user-hostile to me.
> >>>
> >>> Also, how would you picture that working with pg_upgrade?
> >>>
> >>> RULEs are a major feature we've had for over a decade.
> >>
> >> That nobody in the right mind would use in production for YEARS. That
> >> said there is a very real problem here. For a very, very long time
> >> the recommended way (wrong way in fact) to do partitioning was based
> on rules.
> >> Now, those in the know immediately said, "WTF" but I bet you that a
> >> lot of people that we don't know about are using rules for
partitioning.
> >>
> >> We definitely need a warning period that this is going away. That
> >> said, I don't know that we need a whole release cycle. If we start
> >> announcing now (or before the new year) that in 9.3 we will not have
> >> rules, that gives people 9-10 months to deal with the issue and that
> >> is assuming that we are dealing with early adopters, which we aren't
> >> because early adopters are not going to be using rules.
> > My experience suggests that only ample annoyance for at least one full
> > release cycle will provide a low-impact switch. This annoyance must
> > not be able to be turned off.
> >
>
>
> Spot on. All our experience is that just announcing things, especially in
places
> other than release notes and similar, is ineffective as a way of
communicating
> with our user base.
>
> I'm with Tom and Josh and Daniel on this, and to be honest I'm somewhat
> surprised at the willingness of some people to spring surprises on users.
I still
> come across uses of rules in the wild, and not just for partitioning
either.
> Personally I think if we start now the earliest we should even consider
> removing the support is 9.4.
>
> cheers
>
> andrew

Deprecation means that existing code will no longer work without
refactoring. If CREATE RULE was a security hazard or unstable that may
justify such an action but simply because using it properly (or at least
safely) is difficult doesn't mean that those who have managed should be
punished for their expertise.

Late night rambling here but the "risk mitigation" that we seem to be caring
about is new users searching for and using "algorithms" that they find on
the web without understanding the intricacies of how those algorithms work.
Do we really want to build something into the database to deal with this (by
disallowing it outright) or do we do our best to provide authoritative and
useful documentation so that when users go looking for the "CREATE RULE"
command in our documentation they are provided with reasoning and
alternatives to its use?

RULEs may be difficult but maybe there are some rare use-cases where they
would be appropriate. No one here is all-knowing and just maybe someone in
the future will have an idea and decide to further improve them or at the
least recognize a situation where the current implementation is useful.

So, what actual harms are there to using CREATE RULE and are there less
invasive means, via a more nuanced restriction implementation of CREATE RULE
or simply via documentation, to mitigate those harms? Maybe there would not
be enough benefits to CREATE RULE at this point in time to consider
implementing in from scratch but given that it already exists it should be
worth some effort to keep it functioning even if only for
forward-compatibility reasons. And regardless, the whole "what do you use
instead of CREATE RULE" documentation needs to be created no matter the
eventual decision to fully remove the feature from the system.

David J.