Re: Deprecating RULES

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