Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> 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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
