Re: Deprecating RULES

On 13 October 2012 21:15, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> Simon,
>
>> I think its sad we can't even attempt a technical conversation
>> without
>> you making snide ad hominem attacks that aren't even close to being
>> true on a personal level, nor accurate in a technical sense.
>
> I would prefer it if you actually addressed my substantive arguments, which, so far, you haven't.

I would prefer it if you stuck to your substantive arguments, after
reading and understanding others points, which so far, you haven't. So
lets now try and stick to technical points.

Your substantive argument, as I understand it, is that deprecating
something can cause user annoyance at upgrade. I agree with that
point, as I would expect everybody to do so.

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.

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.
Deprecating rules is a much, much smaller change than any of the
recent deprecations. Everything else we say needs to have that
context.

You also mention that we must make noise for at least 18 months before
making any change, to avoid race conditions where new users adopt
RULEs and are then surprised when we deprecate them. My answer to that
is that rules are pretty useless and any reasonable developer will
discover that before putting anything live. 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. 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.

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.

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.

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.

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.

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.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services