Skip site navigation (1) Skip section navigation (2)

RE: 7.1 pg_dump fails for user-defined types (release stopper?)

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pholben(at)greatbridge(dot)com
Subject: RE: 7.1 pg_dump fails for user-defined types (release stopper?)
Date: 2001-03-30 20:27:53
Message-ID: 8F4C99C66D04D4118F580090272A7A234D3363@sectorbase1.sectorbase.com (view raw or flat)
Thread:
Lists: 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 by date

Next:From: Darren KingDate: 2001-03-30 20:30:41
Subject: RE: 7.1 pg_dump fails for user-defined types (release stopper?)
Previous:From: Dominic J. EidsonDate: 2001-03-30 20:20:17
Subject: Re: Re: third call for platforms...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group