Simon, * Simon Riggs (si...@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
signature.asc
Description: Digital signature
