> I can think of a couple of ways to deal with this, the simplest being
> to say "don't do that" --- ie, define widget_in with result type
> "opaque" rather than "widget". That's pretty ugly and will likely
Why is it ugly? Why not update RETURNS type for XXX_in function when
> break people's 7.0 dump scripts all by itself. A more promising idea
Is 7.1 pg_dump able to dump 7.0 database?..
> is to hack function creation so that the OID assigned to the function
> is lower than the OIDs assigned to any shell types created when the
> function is defined.
How much lower? How to guarantee that OID of XXX_out created sometime
after XXX_in will be lower than XXX' OID?
> Or we could try to hack pg_dump to fix this,
> but that doesn't seem appetizing.
It looks like also right way to follow - pg_dump should care about
> There may be similar problems with other shell-catalog-entry cases;
> haven't looked yet.
> Is this a release stopper? I'm inclined to think it is.
Yes, looks like that one -:(
pgsql-hackers by date
|Next:||From: Darren King||Date: 2001-03-30 20:30:41|
|Subject: RE: 7.1 pg_dump fails for user-defined types (release stopper?)|
|Previous:||From: Dominic J. Eidson||Date: 2001-03-30 20:20:17|
|Subject: Re: Re: third call for platforms...|