From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Deprecating RULES |
Date: | 2012-10-22 22:54:02 |
Message-ID: | CAHyXU0wGPOzRNKqfsbzm_ooGW=4qcT0V4oDsXVDRzEwcWwJRZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 19, 2012 at 2:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2012-10-22 22:54:15 | Re: Successor of MD5 authentication, let's use SCRAM |
Previous Message | Marko Kreen | 2012-10-22 21:34:17 | Re: Successor of MD5 authentication, let's use SCRAM |