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

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.

Regards,
Joshua Berry

| Regards
| Pavel Stehule