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
|
Список | 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 по дате отправления: