Re: BUG #12088: pg_upgrade 9.3 -> 9.4rc1 - implicit cast not ported - Mailing list pgsql-bugs

From Marco Colombo
Subject Re: BUG #12088: pg_upgrade 9.3 -> 9.4rc1 - implicit cast not ported
Date
Msg-id CAOYH934Egxpb_1BWB7O=tzAyuZs+LMpZT+KPSCHOQD29nJM8YQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #12088: pg_upgrade 9.3 -> 9.4rc1 - implicit cast not ported  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-bugs
Thanks for the explanation!

Marco Colombo
Il 13/gen/2015 19:41 "Peter Eisentraut" <peter_e@gmx.net> ha scritto:

> On 11/28/14 3:28 AM, ing.marco.colombo@gmail.com wrote:
> > Hi, we have defined some implicit cast in the schema. After pg_upgrade
> > process, these have been dropped and we had to create them again.
> >
> > Cast are defined as:
> >
> > create cast (varchar as numeric) with inout as implicit;
> >
> > create cast (unknown as numeric) with inout as implicit;
> >
> > create cast (unknown as text) with inout as implicit;
> >
> > create cast (unknown as integer) with inout as implicit;
>
> pg_dump doesn't dump these casts.  There is a source code comment that
> explains why:
>
>     /*
>      * As per discussion we dump casts if one or more of the underlying
>      * objects (the conversion function and the two data types) are not
>      * builtin AND if all of the non-builtin objects are included in the
> dump.
>      * Builtin meaning, the namespace name does not start with "pg_".
>      *
>      * However, for a cast that belongs to an extension, we must not use
> this
>      * heuristic, but just dump the cast iff we're told to (via dobj.dump).
>      */
>
> So recreating the casts manually after the upgrade is the best
> workaround at the moment.
>
>

pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: BUG #12088: pg_upgrade 9.3 -> 9.4rc1 - implicit cast not ported
Next
From: eantonini@eidoscode.com
Date:
Subject: BUG #12537: It is not possible to configure postgres to use same timezone of the server.