Re: Deprecating RULES - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Deprecating RULES
Date
Msg-id 50784C64.4060103@agliodbs.com
Whole thread Raw
In response to Re: Deprecating RULES  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Deprecating RULES  (Hannu Krosing <hannu@krosing.net>)
Re: Deprecating RULES  (Darren Duncan <darren@darrenduncan.net>)
Re: Deprecating RULES  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Deprecating RULES  (Michael Nolan <htfoot@gmail.com>)
List pgsql-hackers
> I don't think you're listening, none of those things are problems and
> so not user hostile.

Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile?  Wow, you must
have a very understanding group of users.

Lemme try to make it clear to you exactly how user-hostile you're being:

1. User downloads 9.2 today.
2. User builds a new application.
3. User finds the doc page on RULEs, decides they're a nifty concept.
4. New application includes some RULEs.
5. 9.3 comes out.
6. User schedules a downtime for upgrading.
7. In the middle of the upgrade, at 2am, they get a cryptic warning, and
dump/restore fails.
8. User has to rollback the upgrade.
9. User googles a bunch, eventually finds information on the trigger.
10. User realizes that a bunch of their code, written not 6 months
before, needs to be refactored now.
11. User switches to MongoDB in disgust.

I realize you weren't around when we removed row OIDs, but I was *still*
getting flack from that in 2008.  And we lost entire OSS projects to
other databases because of removing row OIDs.  And those were marked
deprecated for 3 years before we removed them.

> That is exactly what I proposed.

No, it's not.  You proposed inserting a SURPRISE! break-your-application
trigger in 9.3 ... 10 months from now.   With zero warning to our
general user base.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Deparsing DDL command strings
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] explain tup_fetched/returned in monitoring-stats