Re: storing intermediate results in recursive plpgsql functions - Mailing list pgsql-general

From Tom Lane
Subject Re: storing intermediate results in recursive plpgsql functions
Date
Msg-id 15708.1015343589@sss.pgh.pa.us
Whole thread Raw
In response to Re: storing intermediate results in recursive plpgsql functions  (Fran Fabrizio <ffabrizio@mmrd.com>)
Responses Re: storing intermediate results in recursive plpgsql  (Vince Vielhaber <vev@michvhf.com>)
List pgsql-general
Fran Fabrizio <ffabrizio@mmrd.com> writes:
> If that's the case, then this is the second time in a week I've found
> huge errors in this darn PostgreSQL Developer's Handbook I bought.  I'm
> coming very close to tossing this thing in the garbage.

> "When a PL/pgSQL function locks a table, the lock is released when the
> PL/pgSQL function returns".

This is bogus...

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

This is perfectly true: the transaction in which the calling query is
contained also contains the operations executed in the called function.
However, evidently the context misled you to think it meant that the
function has its own transaction.

> This book is really starting to tick me off.  Grr.  I'm amazed that
> there are errors of this magnitude.  The authors are Ewald Geschwinde
> and Hans-Jurgen Schonig, does anyone know their credentials?

Can't say that I recognize either name.  But you might as well let them
know of the mistakes you find, so that they can fix 'em in future
editions (if any).

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dumpall storing multiple copies of DB's?
Next
From: Tom Lane
Date:
Subject: Re: vacuum statistics