From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | Jan Wieck <janwieck(at)yahoo(dot)com> |
Cc: | AGRE Enterprises <agree(at)godzone(dot)net(dot)nz>, pgsql-general(at)hub(dot)org |
Subject: | Re: Stumped on PlPgSql |
Date: | 2000-10-23 21:59:41 |
Message-ID: | Pine.BSO.4.10.10010231758080.31166-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Usually what causes this error for me is following type of code: table x
with column a, and local variable called a. Then, if you are not careful,
it'll refer to the local variable in a where clause, when you intended to
refer to table column.
On Mon, 23 Oct 2000, Jan Wieck wrote:
> Tom Lane wrote:
> > AGRE Enterprises <agree(at)godzone(dot)net(dot)nz> writes:
> > > I have a Plpsgsql function that I have been using in 6.5.1 and it works fine.
> > > The same function on 7.0.2 gives me an error. I have looked in the doc and haven't
> > > seen any change in syntax but maybe Im blind.
> >
> > > The error is
> > > ERROR: parser: parse error at or near "$1"
> >
> > Not much help is it :-(. Apparently there's something wrong with the
> > way the plpgsql function executor is generating plain-SQL queries from
> > your function, but we need more context to tell just what.
>
> Yeah - I know.
>
> The function handler put's out some DEBUG messages in the
> postmaster log (cannot do it as NOTICE since the client
> already got the ERROR during the SPI call). Please tell us
> what these DEBUG messages say. They usually contain a line
> number where it happened inside the function.
>
>
> Jan
>
> >
> > Here's what I'd do to get more info: make sure that the postmaster is
> > creating a log file (you should have started it without -S, and
> > redirected its stdout and stderr to some convenient log file, not
> > /dev/null). Next, run psql with PGOPTIONS set for debugging output
> > level 2 or more, say
> > export PGOPTIONS="-d2"
> > psql yourdb
> > (syntax of setting environment variables varies depending on what
> > shell you use, but hopefully you know what to do for yours). Then,
> > try to execute the function, so that you get the error report. Now
> > you can look in the postmaster's logfile and you will see the exact
> > sequence of queries that the plpgsql function executor tried to submit
> > to the main SQL parser. This will at least narrow down the problem
> > to one line of the plpgsql function. If it's still not clear what's
> > wrong, send in the logged queries and we'll take a look...
> >
> > regards, tom lane
> >
>
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #================================================== JanWieck(at)Yahoo(dot)com #
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dominic J. Eidson | 2000-10-23 22:00:48 | Re: Great Bridge is hiring! |
Previous Message | Lamar Owen | 2000-10-23 21:12:32 | Re: pgsql 7.0.2 on RH6.2 regression test failed |