Merlin Moncure <mmoncure@gmail.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You can't have arithmetic, comparisons, or much of anything
>> outside a transaction with plpgsql. That model just plain
>> doesn't work for this purpose, I think. You really want a
>> control language that's independent of the SQL engine, and for
>> better or worse plpgsql is built inside that engine.
>
> I'm arguing against a separate language, or at least questioning
> if plpgsql truly can't be run without an outer transaction
> context. Just because a transaction isn't set up on procedure
> invocation, doesn't mean you can't set them up to do things in the
> procedure?
Right -- I don't think anyone has suggested that transactions can't
be started and ended "within" a SP. And I have argued that if a SP
is called while a transaction is active, it runs within the context
of that transaction.
> 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.
+1
> You can always dip into a function if/when you need the turbo
> boost.
Or BEGIN a transaction.
> Setting up a new control language implies that postgres needs to
> know the procedure language textually so it can read off a line
> and do something with it. I don't like this restriction --
> wouldn't it be better if the current crop of language handlers
> could run procedures without major changes? C functions with SPI?
> However it's internally implemented, the more userland mindspace
> recovered for use of writing procedures the better off we are.
+1
-Kevin