Re: Deprecating RULES - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Deprecating RULES
Date
Msg-id CAHyXU0wGPOzRNKqfsbzm_ooGW=4qcT0V4oDsXVDRzEwcWwJRZw@mail.gmail.com
Whole thread Raw
In response to Re: Deprecating RULES  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Deprecating RULES  ("David Johnston" <polobo@yahoo.com>)
List pgsql-hackers
On Fri, Oct 19, 2012 at 2:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> As you can see, in the case of rewrite it takes us back 7 1/2 years. I know
>> this is a *very* rough measure, but it still tends to indicate to me that
>> the maintenance burden isn't terribly high.
>
> That's a pretty neat one-liner.  However... in my view, the real cost
> of rules is that they are hard to support as we add new features to
> SQL.  I believe we already decided to punt on making them work with
> CTEs... and maybe one other case?  I don't really remember the details
> any more, but presumably this will come up again with MERGE, and
> perhaps other cases...

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



pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Successor of MD5 authentication, let's use SCRAM
Next
From: Greg Stark
Date:
Subject: Re: Successor of MD5 authentication, let's use SCRAM