Re: Deprecating RULES - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Deprecating RULES
Date
Msg-id 50786226.1080509@krosing.net
Whole thread Raw
In response to Re: Deprecating RULES  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 10/12/2012 06:59 PM, Josh Berkus wrote:
>> 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.
Perhaps more likely p11. is "User starts drinking and gets a divorce. 
His dog dies as a result."

More seriously, if it was something that is easier to do in MongoDB,
the user _should_ switch. And MongoDB does not have RULEs.

I can't think of anything using RULES that would make PostgreSQL
behave like MongoDB.

It can be done using json/htree/xml + pl/jsv8 (or any other pl), but not 
RULES.

> 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.
I'm sure we also lost "entire projects" to other databases _because_

_of_ having 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.
Daniel hinted at a better approach - use a trigger which rewrites all
rules to send a nagging notice at every use of the rule in addition
to what they do originally.




pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Tom Lane
Date:
Subject: Re: dumping recursive views broken in master