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

Re: Deprecating RULES

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deprecating RULES
Date: 2012-10-12 06:42:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 11 October 2012 23:59, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> With the DDL trigger, we're able to do that faster. The idea is you
>> can still delete it if you need compatibility, so we get the message
>> across without an extra release and without an annoying GUC (etc).
> You're seeing these things as bugs.  I see them as features.  And we
> don't need a GUC if you can't turn the warning off.
> 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.

I don't think you're listening, none of those things are problems and
so not user hostile.

I've proposed a trigger that is there by default but which is *removable*.

So you can turn it off, and yet there is no GUC.

> Also, how would you picture that working with pg_upgrade?

If RULEs are in use, we automatically delete the trigger.

> RULEs are a major feature we've had for over a decade.  We've discussed
> deprecating them on -hackers, but believe it or don't, most of our users
> don't read -hackers.  We need to warn people, loudly and repeatedly, for
> at *least* a year and a half before removing RULEs.

That is exactly what I proposed.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-10-12 06:47:26
Subject: Re: Deprecating RULES
Previous:From: Amit KapilaDate: 2012-10-12 06:34:22
Subject: Re: Switching timeline over streaming replication

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