Re: Upgrade from 8.2 to 8.3 & catching errors in functions

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Joshua Berry <yoberi(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Upgrade from 8.2 to 8.3 & catching errors in functions
Date: 2009-10-27 18:57:52
Message-ID: 162867790910271157h320fb428t3f32341055b3dffb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2009/10/27 Joshua Berry <yoberi(at)gmail(dot)com>:
> On Tue, Oct 27, 2009 at 1:35 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> |
> | 2009/10/27 Joshua Berry <yoberi(at)gmail(dot)com>:
> | > Greetings,
> | >
> | > It seems that in Postgresql 8.2 less casting was necessary to coax the
> | > backend to execute queries.
> | > For example:
> | > * Comparing a varchar with a numeric
> | >
> | > In 8.3, these will result in errors like this:
> | > HINT:  No operator matches the given name and argument type(s). You might
> | > need to add explicit type casts.
> | > QUERY:  SELECT  ( $1  <  $2 )
> | >
> | > Is it possible to get the backend to check the function bodies upon loading
> | > of the dump? I've tried this, from the head of the pg_dump generated
> | > dumpfile:
> | >  SET client_encoding = 'UTF8';
> | >  SET standard_conforming_strings = off;
> | > -SET check_function_bodies = false;
> | > +SET check_function_bodies = true;
> | >  SET client_min_messages = warning;
> | >  SET escape_string_warning = off;
> | >
> | > This has caught a few problems, but not most. If it is not possible to do
> | > this, is there (an easy) way to parse the function body relating the known
> | > datatypes of the columns referenced to check for such conflicts?
> |
> | It isn't possible yet.
> |
> | I wrote missing cast functions with notifications. So you can use it
> | on 8.3 for some time and then you can identify mostly problematic
> | places.
>
> Thank you! So before, 8.1 and 8.2 would try to cast to text as a last
> resort? Are there adverse effects that the added casts can cause? My
> plan is to put these casts in place for a time while we are able to
> verify that none of the casts are needed. It would be good to know if
> there are any side effects of using them.
>
These casts was removed because should to hide some bugs. Like cast int to date

with this cast you can to write predicate current_date < 2009-10-10,
it is nonsens, but correct. That is all.

Regards
Pavel

> Regards,
> Joshua Berry
>
> | Regards
> | Pavel Stehule
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2009-10-27 19:02:18 Re: auto truncate/vacuum full
Previous Message Tim Landscheidt 2009-10-27 18:53:55 Re: Procedure for feature requests?