Re: "stored procedures" - use cases?
От | Josh Berkus |
---|---|
Тема | Re: "stored procedures" - use cases? |
Дата | |
Msg-id | 4DB856DE.1080106@agliodbs.com обсуждение исходный текст |
Ответ на | Re: "stored procedures" - use cases? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: "stored procedures" - use cases?
|
Список | pgsql-hackers |
> These don't seem like compelling use cases at all to me. You said you > had to fall back to using a python script outside the database, but > what disadvantage does that have? Why is moving your application logic > into the database an improvement? Since both were part of a code rollout, it complicated our deployment process considerably and took a deployment which could have been push-button automatic and forced us to do it by manually logging into the shell on the database server. > Trying to move all the > code into the database just makes life harder. I might make *your* life harder. It makes *mine* easier. If you pursue your argument a little further, Greg, why do we have functions at all? We could do it all in the application. > Autonomous transactions have value on their own. But it's not so that > you can run create index ocncurrently or vacuum or whatever. Why not? Why are you so intent on making my life harder? > They're > useful so that a single session can do things like log errors even > when a transaction rolls back. That's *also* an excellent use case. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: