Re: storing intermediate results in recursive plpgsql functions

From: "Gregory Wood" <gregw(at)com-stock(dot)com>
To: "Fran Fabrizio" <ffabrizio(at)mmrd(dot)com>
Cc: "PostgreSQL-General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: storing intermediate results in recursive plpgsql functions
Date: 2002-03-05 16:36:07
Message-ID: 012f01c1c463$da5c4110$7889ffcc@comstock.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> >>(apprently sql functions do not automatically end
> >>transactions/release locks like plpgsql functions do)
> >
> > Say what? There's no difference on that score for any kind of function;
> > none of them end transactions or release locks at exit.
>
> "When a PL/pgSQL function locks a table, the lock is released when the
> PL/pgSQL function returns".

I don't see any way in which that could be a true statement. Which is not to
say that it couldn't be a true statement :)

> "You can't have transactions in PL/pgSQL functions. Every function is
> executed in one transaction."

This is a true statement (although not worded very clearly). Let me give a
shot at making it more understandable:

You can not start or end a transaction inside a function. The reason for
that is rather simple: PostgreSQL does not support nested transactions.
Since all functions are already wrapped in a transaction, implicit or
explicit, they are already inside a transaction, and therefore can not start
a new transaction. For the same reason, you can not end a transaction
because the function is considered an atomic action.

Greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bill McGonigle 2002-03-05 16:41:40 Re: pg_dumpall storing multiple copies of DB's?
Previous Message Masaru Sugawara 2002-03-05 16:30:57 Re: help with getting index scan