Re: Error in creating the backend query - Mailing list pgsql-admin

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@postgresql.org [mailto:pgsql-admin-
> owner@postgresql.org] On Behalf Of Benjamin Krajmalnik
> Sent: Wednesday, July 29, 2009 5:00 PM
> To: Tom Lane
> Cc: Alvaro Herrera; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] 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@sss.pgh.pa.us]
> > Sent: Wednesday, July 29, 2009 4:43 PM
> > To: Benjamin Krajmalnik
> > Cc: Alvaro Herrera; pgsql-admin@postgresql.org
> > Subject: Re: [ADMIN] Error in creating the backend query
> >
> > "Benjamin Krajmalnik" <kraj@illumen.com> 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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin