Re: Deprecating RULES

On Thu, Oct 11, 2012 at 8:52 PM, Andrew Dunstan <andrew(at)dunslane(dot)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