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

Re: "stored procedures"

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "stored procedures"
Date: 2011-09-01 17:49:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Sep 1, 2011 at 1:18 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 8/31/11 12:15 PM, Merlin Moncure wrote:
>> An out of process, autonomous transaction type implementation should
>> probably not sit under stored procedures for a number of reasons --
>> mainly that it's going to expose too many implementation details to
>> the user.  For example, does a SP heavy app have 2*N running
>> processes?  Or do we slot them into a defined number of backends for
>> that purpose? Yuck & yuck.  I like the AT feature, and kludge it
>> frequently via dblink, but it's a solution for a different set of
>> problems.
> I think that transaction control without parallelism would be the 80%
> solution.  That is, an SP has transaction control, but those
> transactions are strictly serial, and cannot be run in parallel.  For
> example, if you were writing an SP in PL/pgSQL, each "BEGIN ... END"
> block would be an explicit transaction, and standalone-only statements
> be allowed between BEGIN ... END blocks, or possibly in their own
> special block type (I prefer the latter).
> One issue we'd need to deal with is exception control around
> single-statement transactions and non-transactional statements (VACUUM,
> CREATE INDEX CONCURRENTLY, CHECKPOINT, etc.).  In some cases, the user
> is going to want to catch exceptions and abort the SP, and in other
> cases ignore them, so both need to be possible.

Yep, "+1" on that.

Leaving out parallelism, and having the mechanism operate under the
auspices of a single connection, makes a fine start, and perhaps is
enough even in the longer run.
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-09-01 18:07:11
Subject: Re: pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge
Previous:From: Tom LaneDate: 2011-09-01 17:36:12
Subject: Re: Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

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