Re: problem with casts dump/restore

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: problem with casts dump/restore
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A75A7@Herge.rcsinc.local
обсуждение исходный текст
Ответ на problem with casts dump/restore  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Ответы Re: problem with casts dump/restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > I just noticed that pg_dump does not seem to be exporting at least
one
> > of my user defined casts...In particular, this one:
>
> > CREATE CAST (xid AS oid)
> >   WITHOUT FUNCTION;
>
> This is per design, more or less:
>
>     /*
>      * 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 namespaces are
>      * included in the dump. Builtin meaning, the namespace name does
not
>      * start with "pg_".
>      */
>
> (The discussion in question is from late Sept 2003.)
>
> The problem is basically that there's no way to detect that this isn't
a
> built-in cast.
>
> In 7.3 and later there is another way to attack that question, which
is
> to look to see if there's a "pin" dependency in pg_depend for the
cast.
> Kinda ugly but it might do.

Hmm...well, that makes perfect sense.  I suppose it's easy enough to
work around the problem by splitting the cast in two, and that's not
necessarily bad style, IMO.

The reason why I did that to begin with was to be able to do some
in-query processing on a xid.  Is it intentional that oid has a built in
cast to integer and xid does not?

Merlin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: problem with casts dump/restore
Следующее
От: Andrew Dunstan
Дата:
Сообщение: buildfarm switching servers