Re: Deprecating RULES - Mailing list pgsql-hackers

Simon,

* Simon Riggs (simon@2ndQuadrant.com) wrote:
> You also mention that 3 years wasn't long enough for some people, but
> I am unsure as to your point there. It might be that we should take
> longer than 3 years to deprecate things, or that the same pain will be
> felt however long we leave it. I think the latter, since the standard
> conforming strings change didn't go much better even though we took
> ages to do it.

RULEs, being what they are, deserve at least 3 years, imo.

> In many people's opinion, RULEs are a strangeness that are seldom used
> in production and long since should have been removed. Peter shows a
> paper that details things wrong with them from 15 years ago.

Indeed.  Unfortunately, our documentation doesn't reflect that (yet).

> Deprecating rules is a much, much smaller change than any of the
> recent deprecations. Everything else we say needs to have that
> context.

It's smaller.  I don't agree that it's "much, much smaller".

> My answer to that
> is that rules are pretty useless and any reasonable developer will
> discover that before putting anything live.

To be honest, I don't believe we would be having this discussion were
your statement above accurate.  RULEs are used quite a bit 'in the
wild', as it were, particularly to address our lack of proper
partitioning.

> If they do put it live,
> they might not have noticed rules are actually broken, so deprecating
> rules in this way will actually avoid bugs and data corruption for
> those people.

Your proposal was to explicitly break RULEs for them on an upgrade,
wasn't it..?  Or did you propose something else?  Regardless of *how*
that breakage happens, I do not believe our users would appreciate RULEs
breaking without sufficient notice for them to do something about it.  I
understand your suggestion that they could simply remove the breakage,
but I do not agree that it is sufficient for them.  Either they will do
it as a matter of course during the upgrade and promptly forget about
it, or they'll decide that they need to fix it in a very tight timeframe
leading up to their upgrade (after they discover it in testing)- neither
is good.

> For me, most developers either 1) use ORMs, none of
> which use RULEs, 2) speak to people in PostgreSQL community/consulting
> companies - almost all of whom will advise to avoid RULEs or 3) have
> read books that advise against their use or 4) read that rules are not
> SQL standard and so wisely avoid unnecessarily non-standard coding. As
> a result, I think the number of people likely to adopt rules in the
> near future is approximately zero and the number affected by this
> change will be very low and unlikely to cause embarrassment for us.

I completely disagree with this while our documentation talks about it,
describes it as a user feature, and even encourages use of RULEs for
partitions.  Indeed, changing the documentation would be the correct
first step to deprecating RULEs.

> IMHO the risk of losing people to other databases seems higher from
> providing broken features than it does from removing broken features,
> which seems like useful and proactive management. Since I believe
> there is something to be lost from maintaining the status quo, and
> little to be gained from delay, I proposed a way of speeding up the
> process that allowed a back out plan.

Personally, I don't believe your plan is sufficient with regard to
giving users time to move off of RULEs.  I don't disagree that we need
to get rid of them as a user-visible/encouraged feature.

> Daniel has made the point that we must enforce deprecation without any
> option of reversion. Given neither of us likes to be hostile to users,
> I presume we both disagree with him on that? One thing I would like to
> avoid is providing another GUC for compatibility, since the
> combinatorial explosion of GUC settings introduces considerable bug
> risks.

I agree that we can't simply disable them in the next release.  My
suggestion would be along the lines of: updating our documentation,
issuing a warning when they're used in our next major release, make them
only something a superuser can create, eventually make them unable for
anyone to create.

> Having said that, I've got no particular reason to hurry other than my
> own personal embarrassment at explaining that, yes, some of our
> features are broken. But I would like to see actions begin, however
> long the timescale.

Let's, please, start with a communication plan that is initiatied by
updating our documentation and making an announcement to -announce
regarding the planned deprecation of RULEs.

> If we wish to make some noise, I think docs changes are not enough.
> Darren's suggestion that doc additions that explain that advice has
> been backpatched is useful, but we should also make Announcements of
> impending deprecations as well if we truly wish to make noise. And if
> we do that, as Daniel points out, sorting out hash indexes at the same
> time also makes sense.

Wrote the above before reading this, so- agreed.

> Where rules do exist it seems possible to write simple code to
> transform them into triggers or views. I'll write some docs to
> explain.

That would be fantastic and would be an execellent resource to refer to
in the announcment and the updated documentation... :)
Thanks!
    Stephen