Skip site navigation (1) Skip section navigation (2)

Re: Deprecating RULES

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,Josh Berkus <josh(at)agliodbs(dot)com>,Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deprecating RULES
Date: 2012-10-12 15:08:37
Message-ID: 20121012150837.GA4460@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Oct 11, 2012 at 05:20:14PM -0700, Daniel Farina wrote:
> On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake <jd(at)commandprompt(dot)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.

As a reminder, standard_conforming_strings and escape_string_warning
were added in PG 8.1 (2005-11-08), and we defaulted
standard_conforming_strings to 'on' in PG 9.1 (2011-09-12).  The reason
it took  six years to change the default to treat backslashes literally
is because the change could produce incorrect results.  In the RULE
case, it will just cause an error when the rule is created, and
hopefully someone will see that.  However, there will be no error when
someone issues a query and the rule is _missing_ because it threw an
error on rule creation.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-10-12 15:28:01
Subject: Re: line type
Previous:From: Tom LaneDate: 2012-10-12 14:59:39
Subject: Re: velog + vereport?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group