From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "stored procedures" |
Date: | 2011-04-21 16:38:39 |
Message-ID: | 24724.1303403919@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-04-21 16:39:44 | Re: Formatting Curmudgeons WAS: MMAP Buffers |
Previous Message | Kevin Grittner | 2011-04-21 16:32:03 | Re: getting to beta |