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: | Raw Message | Whole Thread | 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 |