On 10/12/2012 05:47 AM, David Johnston wrote:
-----Original Message-----
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Andrew Dunstan
Sent: Thursday, October 11, 2012 8:52 PM
To: Daniel Farina
Cc: Joshua D. Drake; Josh Berkus; Simon Riggs;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Deprecating RULES
On 10/11/2012 08:20 PM, Daniel Farina wrote:
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake
<j...@commandprompt.com> wrote:
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it into 9.3 because of the DDL
trigger, especially if they might not encounter it until halfway
through a restore. That seems rather user-hostile to me.
Also, how would you picture that working with pg_upgrade?
RULEs are a major feature we've had for over a decade.
That nobody in the right mind would use in production for YEARS. That
said there is a very real problem here. For a very, very long time
the recommended way (wrong way in fact) to do partitioning was based
on rules.
Now, those in the know immediately said, "WTF" but I bet you that a
lot of people that we don't know about are using rules for
partitioning.
We definitely need a warning period that this is going away. That
said, I don't know that we need a whole release cycle. If we start
announcing now (or before the new year) that in 9.3 we will not have
rules, that gives people 9-10 months to deal with the issue and that
is assuming that we are dealing with early adopters, which we aren't
because early adopters are not going to be using rules.
My experience suggests that only ample annoyance for at least one full
release cycle will provide a low-impact switch. This annoyance must
not be able to be turned off.
Spot on. All our experience is that just announcing things, especially in
places
other than release notes and similar, is ineffective as a way of
communicating
with our user base.
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.
cheers
andrew
Deprecation means that existing code will no longer work without
refactoring. If CREATE RULE was a security hazard or unstable that may
justify such an action but simply because using it properly (or at least
safely) is difficult doesn't mean that those who have managed should be
punished for their expertise.
Late night rambling here but the "risk mitigation" that we seem to be caring
about is new users searching for and using "algorithms" that they find on
the web without understanding the intricacies of how those algorithms work.
Do we really want to build something into the database to deal with this (by
disallowing it outright) or do we do our best to provide authoritative and
useful documentation so that when users go looking for the "CREATE RULE"
command in our documentation they are provided with reasoning and
alternatives to its use?
RULEs may be difficult but maybe there are some rare use-cases where they
would be appropriate.
I have missed SELECT rules on real tables a few times, but I do not
remember that there was much outcry when they were disabled.
On the other hand, I do not miss them much, as my experience with
rules in general is that they are brittle - even if
you can get them to work for your current use, there is no guarantee
that they keep working after changes to queries or table structure.
So restricting the SELECT rules to what can be defined in CREATE VIEW
seems a good compromise.
You can (in theory) train yourself in proper use of foot-guns, but you
can never be absolutely sure that you have reached the appropriate
level for using them in real-life situations where a broken foot is not
desirable.
No one here is all-knowing and just maybe someone in
the future will have an idea and decide to further improve them or at the
least recognize a situation where the current implementation is useful.
So, what actual harms are there to using CREATE RULE and are there less
invasive means, via a more nuanced restriction implementation of CREATE RULE
or simply via documentation, to mitigate those harms? Maybe there would not
be enough benefits to CREATE RULE at this point in time to consider
implementing in from scratch but given that it already exists it should be
worth some effort to keep it functioning even if only for
forward-compatibility reasons. And regardless, the whole "what do you use
instead of CREATE RULE" documentation needs to be created no matter the
eventual decision to fully remove the feature from the system.
David J.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
