I wish that were the case. I am running 8.3.7 built from the FreeBSD ports. All insertions and updates to that table (or any others) are done exclusively through that (or other) stored procedures. We only use ad-hoc queries for selecting data for presentation purposes. Our code does not cast any column to its type. Just to make sure that this was indeed the source, we went ahead and typecast one of the assigned values, and the generated code had a "double cast", such as Column = 'value'::VARCHAR::varchar So the plpgsql stored procedure is definitely the source. We have worked around this by setting the variable to a blank string if the value passed to the stored procedure is a null value, but there definitely appears to be an issue in there. > -----Original Message----- > From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] > Sent: Wednesday, July 29, 2009 4:43 PM > To: Benjamin Krajmalnik > Cc: Alvaro Herrera; pgsql-admin@xxxxxxxxxxxxxx > Subject: Re: Error in creating the backend query > > "Benjamin Krajmalnik" <kraj@xxxxxxxxxxx> writes: > > Below is the full stored procedure. > > All I can do is repeat that plpgsql does not behave that way. It never > has AFAIR, and it most definitely doesn't in any version new enough to > recognize the COST option to CREATE FUNCTION (ie, 8.3 and up). In > fact, > I don't believe that commands executed in a plpgsql function will get > logged at all in 8.3 or later --- they are not according to my tests. > > Perhaps you are running some largely hand-hacked local version of > plpgsql? > Perhaps you're just confused about what's generating the log entry? > > regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
