2009/10/27 Joshua Berry <yoberi@gmail.com>:
> On Tue, Oct 27, 2009 at 1:35 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> |
> | 2009/10/27 Joshua Berry <yoberi@gmail.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
>