To: "Dan Langille" <dan@langille.org>
Cc: pgsql-sql@postgresql.org
Subject: Re: 
In-reply-to: <3F7706FC.13057.3006C804@localhost> 
References: <20030928151910.S78282@laptop.unixathome.org>
	<3F7706FC.13057.3006C804@localhost>
Comments: In-reply-to "Dan Langille" <dan@langille.org>
	message dated "Sun, 28 Sep 2003 16:06:20 -0400"
Date: Sun, 28 Sep 2003 16:14:44 -0400
Message-ID: <10977.1064780084@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Dan Langille" <dan@langille.org> writes:
> However, the results are confusing.  I'm getting the wrong number of 
> parameters.  The value being returned appears to be the value 
> supplied.  But the log results show an interesting pattern in the 
> number of selects being run.

I dunno where the cast() queries are coming from, but note that they're
not your SELECT.  You are misunderstanding how the code works if you
expect to see query LOG entries from plpgsql queries.  For a
non-EXECUTEd plpgsql command, log_statement will only show the query the
first time it is executed in a session, because that log entry is
generated as a side-effect of parsing and planning.

As a means of tracing the execution of plpgsql functions, log_statement
is pretty worthless :-(.  I would like us to develop a full-up tracing
and debugging facility for plpgsql, but we haven't got it yet.

			regards, tom lane