Merlin Moncure <mmonc...@gmail.com> wrote: > Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
