RE: 7.1 pg_dump fails for user-defined types (release s topper?)
| От | Mikheev, Vadim |
|---|---|
| Тема | RE: 7.1 pg_dump fails for user-defined types (release s topper?) |
| Дата | |
| Msg-id | 8F4C99C66D04D4118F580090272A7A234D3363@sectorbase1.sectorbase.com обсуждение исходный текст |
| Список | pgsql-hackers |
> 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 creating type? > 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 system dependancies. > 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 -:( Vadim
В списке pgsql-hackers по дате отправления: