Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Apr 22, 2011, at 11:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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