Re: problem with casts dump/restore

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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

"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> 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?

I'm not sure how intentional it is, but doing integer arithmetic on XIDs
seems pretty fraught with peril to me. The comparison semantics on XIDs
are quite unlike normal integer comparisons.

regards, tom lane