Ken Corey wrote:
> Wow! Answering emails on a Sunday? Someone should be giving you an award or
> something.
>
> On Sunday 04 February 2001 8:13 pm, you wrote:
> > Ken Corey <[EMAIL PROTECTED]> writes:
> > > When the select at the bottom of this email is executed, I'm getting the
> > > message:
> > > ERROR: parser: parse error at or near "$1"
> >
> > I don't get that; I get
> > ERROR: Attribute 'username_in' not found
> > which is about what I'd expect for the given function text; maybe you
> > didn't transcribe it accurately?
>
> That's strange...perhaps the difference was a problem with my table
> definition? *shrug* I also had made a few mistakes, so once I got those
> fixed, the code seems to work again.
>
> > Anyway, an invaluable technique for debugging plpgsql functions is to
> > start psql with debug level 2, so that the queries the plpgsql executor
> > feeds to the SQL engine get logged in the postmaster log. (If you don't
> > run the postmaster with a logfile, you should...) For example:
>
> Hey, that's perfect. It's okay just so long as the debugging out goes
> *somewhere*...:^)
Another lesser known trick is to add
#option dump
at the top of the function body (before DECLARE). This
causes the PL/pgSQL compiler to dump out the entire function
after parsing where you can see all the SPI queries that
later will get executed.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
