Robert Haas <robertmh...@gmail.com> wrote: > On Apr 22, 2011, at 11:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I'd like a pony, too. No ponies for me; make mine an Arabian stallion. >> Let's be perfectly clear about this: there is no part of plpgsql >> that can run outside a transaction today, and probably no part of >> the other PLs either It's a good thing that nobody is suggesting that transactions can't be started and terminated at need within a SP. And I'm not suggesting that a SP couldn't be run within a transaction to avoid the overhead of that, when desired. > Correct me if I am wrong here, but the basic issue is, I think, > that an error might occur. And transactions are how we make sure > that when control returns to the top level, we've released any > heavyweight locks, lightweight locks, buffer pins, backend-local > memory allocations, etc. that we were holding when the error > occurred. If that's the issue, then the biggest problem would seem to be in preparing an SP which isn't within an existing transaction at startup. As someone previously mentioned, there would need to be a transaction to prepare it for execution which would then be completed before processing the body of the SP. Yes, that's hand-wavy, but I thought we were at the phase of brainstorming about what would make for desirable features, not mapping out the implementation details. Of course it's valuable to identify possible implementation issues for such desirable features, even this early; but let's not get bogged down in such details before we reach some kind of consensus on what we might all like. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers