Re: Stumped on PlPgSql
От | Alex Pilosov |
---|---|
Тема | Re: Stumped on PlPgSql |
Дата | |
Msg-id | Pine.BSO.4.10.10010231758080.31166-100000@spider.pilosoft.com обсуждение исходный текст |
Ответ на | Re: Stumped on PlPgSql (Jan Wieck <janwieck@yahoo.com>) |
Список | 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@godzone.net.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@Yahoo.com # > > >
В списке pgsql-general по дате отправления: