Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> I classify this problem as a bug. Objections?
>
> The question is not whether it is a bug, the question is what is correct
> behavior instead.
Not yet, but when we have a decision and a fix it'll be the criterium
for applying it to 7.4 and maybe backpatch into 7.3.
>
>> IMHO a binary compatible cast should be dumped if one or both namespaces
>> of the underlying data types is included in the dump.
>
> That would just replace one bug with another (viz, failure to restore
> if one of the datatypes wasn't included in the dump). Also, what of
> user-defined casts between two system datatypes? pg_catalog is never
> considered part of the dump AFAIR.
>
> The first idea that came to mind is to dump the cast if both underlying
> types are either system types or included in the dump. But I think that
> would end up dumping built-in binary casts, which is no good either.
> I hate to think of looking at the cast's OID vs. lastsysoid to decide
> if it was a built-in cast, but maybe there's no other way.
User defined casts between builtin types are a bad thing anyway. They
are only good for special backward compatibility cases or to support
applications that are broken by design anyway. And a user defined binary
cast between builtin types is just the worst case. Thus, braking the
application with every dump+restore to remind the programmer that
there's still something he has to fix is the _right thing_.
CREATE CAST for that beast should spit out a popup asking
"Do you really ..."
with "No" being the default! Well, a WARNING might do for now.
That eliminated, a cast should be dumped if one or more of the three
objects (source, target and function) are not builtin AND all the
non-builtin objects belong to namespaces included in the dump.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #