I believe you may be right - need to do some more testing. Apparently the error which I saw in the log was generated while debugging the stored procedure using SQL Studio for PostgreSQL. I guess it has its own interpreter for plpgsql and must be typecasting while executing each row. We can consider this closed unless I see it occur again. Sorry for the false alarm. > -----Original Message----- > From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin- > owner@xxxxxxxxxxxxxx] On Behalf Of Benjamin Krajmalnik > Sent: Wednesday, July 29, 2009 5:00 PM > To: Tom Lane > Cc: Alvaro Herrera; pgsql-admin@xxxxxxxxxxxxxx > Subject: Re: Error in creating the backend query > > 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
