On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut <pete...@gmx.net> wrote: > On fre, 2011-04-22 at 08:37 -0500, Merlin Moncure wrote: >> It wouldn't bother me in the lest that if in plpgsql procedures if you >> had to set up and tear down a transaction on every line. > > It would probably be more reasonable and feasible to have a setup where > you can end a transaction in plpgsql but a new one would start right > away.
ya, that's an idea. if nothing else, it would certainly be faster, and you still be able to control things properly. Just thinking out loud here, but maybe you could make a cut down version of StartTransaction() that does non-transactional set up like memory, guc, etc but doesn't set the state (or set's it to something else, like TRANS_PROCEDURE). We get here maybe by a new protocol firstchar. One thing that's not clear is how you'd get there via a simple query (sent via PQexec vs hypothetical PQcall). The protocol and syntax portions are a whole separate issue anyways... I poked around a bit in pl_exec.c and and pl_handler.c. My thinking is that in strategic points, in particular in exec_stmt(), you check if in procedure state and not already in a transaction, set one up there, run the statement, and take it down afterwords. Maybe you do this on every statement, or maybe as Peter suggest it's user controlled, but i'm curious how this would turn out. You'd also have to be in a transaction during the function call setup/compilation, and the portions that handle the input arguments. However the main execution loop which passes over the exec state istm is fairly self contained and won't be problematic if run outside of transaction. This is the key point -- the SPI routines when run would always be in *a* transaction, just not always the same transaction. :-) What exactly SPI_connect does, and what the other SPI functions would do if invoked from a different transaction is a mystery to me and presumably a big problem. I'm quite aware this is all awfully light on detail, and the million + 1 assumptions I'm making, but since your getting basically injected directly into a function from the tiny lizard brain of postgres in tcop, I wonder if it could be worked out... merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers