Re: pg_dump of regression db?

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> At 12:34 13/09/00 -0400, Tom Lane wrote:
>> The command needs to read "basetype = any".

> The particular piece of code (findTypeByOid) that does this is used to
> display types other places (eg. function return types). My guess is that I
> should use the new 'format_type' function in these as well, and have a flag
> for the specific case of the aggregate dumping code.

> So I would build the type info table with a new column that contains
> 'typedefn', which is just the output of format_type(typeid, NULL), and
> pass an 'opaque as any' flag when dumping aggregates.

> Does this sound reasonable?

That would solve the immediate issue, but you might want to look a
little further ahead. The real problem here is that a zero typeid is
(mis) used for several different purposes in the existing backend code.
In this context we see two of them: zero representing "any input
datatype is accepted by this function" and zero representing "opaque
type". When you look at the uses of "opaque" you find that that has
several different meanings as well. Eventually I would like to clean
this up by inventing distinct typeids for each shade of meaning ---
we already have one special typeid of this sort (UNKNOWN) and it seems
like having several of them would be a cleaner way to proceed than
overloading zero with such wild abandon.

I'm not entirely sure what that means for pg_dump; maybe it means that
the problem goes away and just printing the format_type output will
work in all contexts. But for now you should consider that there are
several different possible interpretations of typeid zero. In short,
pass an enum not a boolean...

>> No, the known problem is that ALTER TABLE on a inheritance hierarchy
>> screws up the column ordering of the child tables:

> Am I correct that someone was working on allowing a column order to be
> specified in COPY commands? If so, this would fix the problem, I think.

No, that is a kluge that would allow pg_dump to work around ALTER
TABLE's fundamental inadequacy. It's not a fix unless you think it's OK
to expect every application forevermore to take special care with column
orders.

regards, tom lane