> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Merlin Moncure
> Sent: Monday, October 22, 2012 6:54 PM
> To: Robert Haas
> Cc: Andrew Dunstan; Josh Berkus; Daniel Farina; pgsql-
> hackers@postgresql.org
> Subject: Re: [HACKERS] Deprecating RULES
> >
> Good point on the CTE (and it's correct). I think by any reasonable
definition
> rules are in fact already de facto deprecated: they are not being extended
to
> interact with other features and the community is advising against their
use.
> I don't think anybody would complain if/when a hypothetical MERGE feature
> was advanced without rule interaction.
>
> That said, I don't think there is any reasonable argument to remove rules.
> Backwards compatibility should only be broken when it *must* be broken.
> Any 'developer interest only' standards ('grotty code', 'inelegant', 'ill
advised
> for new code', etc) of removal are completely specious and thus are IMSNHO
> irrelevant.
>
> merlin
While I agree with this sentiment to some degree in order for the community
to thrive new developer blood needs to be introduced periodically. Not that
this feature is particularly an issue but making the codebase easier to
learn and maintain has considerable value in its own right.
To put a different spin on things it is like CREATE RULE is a specialty
tool. Taken that way we should strictly describe the uses-cases where
CREATE RULE behavior is well-defined and problem free. If the end-user
isn't trying to use RULEs in exactly those cases then they are advised to
attempt another solution or send an e-mail to the list to get some expert
opinions on that particular use-case. Known problematic uses can also be
listed to minimize the amount of "not listed, what do y'all think" e-mails
sent to the list. In this setup there is some developer obligation to try
and not break those "well-defined" use-cases; but that exists today even if
it is not explicitly mentioned.
David J.
