Re: Deprecating RULES - Mailing list pgsql-hackers

On Oct 17, 2012, at 4:45 PM, Daniel Farina wrote:

> On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 10/17/12 12:57 PM, Daniel Farina wrote:
>>> I'll have to register my disagreement then, in the special case where
>>> a feature becomes so obscure that many people don't have a wide-spread
>>> intuition at what it's good at or used for.  Tom also said "build the
>>> replacement," and without itemization of use cases, I don't even know
>>> what that would look like -- perhaps such knowledge is assumed, but I
>>> think it's assumed wrongly, so perhaps there just needs to be some
>>> education.  At best you could define what to build somewhat
>>> tautologically from the mechanism used by RULES, and that's not a very
>>> good way to go about it, methinks.
>
> [use case, redacted, although worth independent consideration]
>
>> Putting it as "Andrew and Josh need to enumerate these cases, or forever
>> be silent" is quite unfair to our users.  Andrew and I hardly represent
>> the entire scope of PostgreSQL app developers.  Enumerating the cases,
>> finding replacements for them, and documenting migrations needs to be a
>> group effort.
>
> Unfortunately I myself see little evidence of the vast, vast --
> several nines of vast -- majority of folks using rules, and as I said:
> as a thought experiment, merely one solved bug is worth more to me
> than rules from what I know at this time.  If I had a wealth of user
> pain to draw upon, I would have in opposition to their deprecation.
> But, I don't, so I am cautiously in favor of pipelining a slow
> deprecation, even though I can only be hurt by the process tactically

I am a lurker here, and as such, understand that I have no standing.  But I do write internal applications using
postgresqland it seems to me that the direction forward is clear.  I've just went back and read the 9.2 documentation
onRules.  It appears that Rules are a current supported and best solution to many problems.  So as previously stated
andI think pretty much agreed the docs must be changed.  I did not pick up from the docs that there were the problems
mentionedin the various emails. 

With that said, having read each email, there are some politics that do not make sense.

Are these the facts?

1. Rules are required in the core.  For example, that is how views are implemented.
2. There are some, possibly fringe, use cases where Rules are the best solution.
3. There are many uses of Rules that are fragile, or even broken in implementation.

4. There is a desire to make Rules an internal core functionality only.
or
5. There is a desire to eliminate Rules all together.

6. There is new functionality that does not work correctly considering Rules.  (e.g. Rules code is not updated.)

It would seem to me that with #1 and #2 it is foolish (to me, not understanding the politics) to consider deprecation.

The real issue is, "Should Rules be visible to users?"

As an application developer, I do not use Rules because they are non standard and my code will be used by different
backends, so personality I have no skin in this decision.  But logically, I think that it is silly to consider
deprecationat this time.  The time to consider deprecation is when no core functionality depends on Rules.  Until that
time,there is nothing to be gained by deprecation and there is no reason to piss off users by deprecation of code that
hasto be maintained anyway. 

So I would move the docs to the internal section, state that Rules are not recommended to be used in user SQL, and that
Rulesmay be deprecated in the future, then leave things alone for a couple of years until the way forward becomes
clear. If developers want to deprecate Rules, then create code that eliminates Rules from being require for core
functions.

It seems to me that eventually Rules will suffer bit rot and it will be clear that it is time to remove all traces, or
Ruleswill be maintained (albeit possibly less scope) and they will continue as core functionality based on need. 

Neil