Re: Deprecating RULES

On 10/12/2012 05:47 AM, David Johnston wrote:
>> -----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.
I have missed SELECT rules on real tables a few times, but I do not
remember that there was much outcry when they were disabled.

On the other hand, I do not miss them much, as my experience with
rules in general is that they are brittle - even if
you can get them to work for your current use, there is no guarantee
that they keep working after changes to queries or table structure.

So restricting the SELECT rules to what can be defined in CREATE VIEW
seems a good compromise.

You can (in theory) train yourself in proper use of foot-guns, but you
can never be absolutely sure that you have reached the appropriate
level for using them in real-life situations where a broken foot is not
desirable.

> 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.
>
>
>
>
>