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
>
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? |