Re: Deprecating RULES
От | Hannu Krosing |
---|---|
Тема | Re: Deprecating RULES |
Дата | |
Msg-id | 50786226.1080509@krosing.net обсуждение исходный текст |
Ответ на | Re: Deprecating RULES (Josh Berkus <josh@agliodbs.com>) |
Список | 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 по дате отправления: