Re: Deprecating RULES - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Deprecating RULES |
Date | |
Msg-id | CA+TgmobDRqKRfndzxEJQdYQkexLR1Mhyc8vixX=QUi=q9c64Jg@mail.gmail.com Whole thread Raw |
In response to | Re: Deprecating RULES (Andrew Dunstan <andrew@dunslane.net>) |
Responses |
Re: Deprecating RULES
|
List | pgsql-hackers |
On Thu, Oct 11, 2012 at 8:52 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > I'm with Tom and Josh and Daniel on this, and to be honest I'm somewhat > surprised at the willingness of some people to spring surprises on users. I > still come across uses of rules in the wild, and not just for partitioning > either. Personally I think if we start now the earliest we should even > consider removing the support is 9.4. Yeah. Actually, I think even that is far too soon. Frankly, the fact that several people here seem to think rules are still something they see regularly in the field makes me wonder if we should be entertaining this proposition at all ... but if we are, what I think we should do first is add a warning to the documentation that says "don't use rules". And then after, say, two releases, we could have the CREATE RULE command throw a warning. And then after, say, two more releases, we could have it fail with an error saying, dude, not supported any more. That means we would start to warn no earlier than 9.5 and actually shut it off no earlier than 9.7. The case of standard_conforming_strings has already been discussed as a parallel. I think the case of => should also be mentioned. The SQL standards committee has standardized this as a way of calling functions with named arguments, but we have long allowed it as an operator - and in fact hstore has long shipped an operator with that name. We began warning about the use of that operator name in 9.0, and we removed the version that ships with hstore in 9.2. I can't imagine we'll actually implement the SQL standard behavior any sooner than 9.4. The thing we've got to keep in mind here is that many people upgrade more than one release at a time. We regularly have customers who will upgrade from, say, 8.2 or 8.3 all the way up to 9.1 or 9.2. Now, we can't completely cater to people who are on that kind of very long time scale or we'll never get anywhere, but cutting out a feature that isn't even deprecated today in less than a year is going to the opposite end of the spectrum. We know that rules are a bad fit for almost everything, *but we can't assume that our users all know that when it isn't even documented*. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: