| From: | Josh Berkus <josh(at)agliodbs(dot)com> | 
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: "stored procedures" - use cases? | 
| Date: | 2011-04-27 17:48:14 | 
| Message-ID: | 4DB856DE.1080106@agliodbs.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dan Ports | 2011-04-27 17:59:14 | Re: SSI non-serializable UPDATE performance | 
| Previous Message | Simon Riggs | 2011-04-27 17:26:52 | Re: SSI non-serializable UPDATE performance |