Re: "stored procedures"

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "stored procedures"
Date: 2011-04-21 16:42:30
Message-ID: BANLkTinxP2-+BHpV-jb6MSQLhpi=dgezow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 21, 2011 at 12:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> EDB has an implementation of this in Advanced Server.  A stored
>> procedure can issue a COMMIT, which commits the current transaction
>> and begins a new one.  This might or might not be what people are
>> imagining for this feature.  If we end up doing something else, one
>> thing to consider is the impact on third-party tools like PGPOOL,
>> which currently keep track of whether or not a transaction is in
>> progress by snooping on the stream of SQL commands.  If a procedure
>> can be started with no transaction in progress and return with one
>> open, or the other way around, that method will break horribly.
>> That's not necessarily a reason not to do it, but I suspect we would
>> want to add some kind of protocol-level information about the
>> transaction state instead so that such tools could continue to work.
>
> Huh?  There's been a transaction state indicator in the protocol since
> 7.4 (see ReadyForQuery).  It's not our problem if PGPOOL is still using
> methods that were appropriate ten years ago.

Hmm. Well, maybe we need some PGPOOL folks to weigh in. Possibly
it's just a case of "it ain't broke, so we haven't fixed it".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-21 16:45:57 Re: fsync reliability
Previous Message Robert Haas 2011-04-21 16:41:05 Re: getting to beta