> 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.
Also, how would you picture that working with pg_upgrade?
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. So, to expand on my
sequence of events:
1. Figure out how to 100% replace all functionality currently offered by
RULEs (this may already exist, but nobody has accounted it)
2. Announce that RULES will be going away after 9.4 (in 2015).
3. Amend the documentation pages on RULEs with a fat header saying this
is a deprecated feature and going away in 2 versions.
4. Write wiki pages describing how to migrate away from RULEs.
5. In 9.4, send a warning every time someone CREATEs/ALTERs a
user-defined RULE.
6. In 10.0, get rid of CREATE RULE.
Note that steps 1-4 would need to be complete at least a year before
RULEs actually go away ... preferably 2 years. And 100% of the
functionality required to replace RULEs needs to be available at least
one version before RULEs go away, preferably 2 versions.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com