Skip site navigation (1) Skip section navigation (2)

Re: "stored procedures" - use cases?

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Dan PortsDate: 2011-04-27 17:59:14
Subject: Re: SSI non-serializable UPDATE performance
Previous:From: Simon RiggsDate: 2011-04-27 17:26:52
Subject: Re: SSI non-serializable UPDATE performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group