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

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

From: Mike Mascari <mascarm(at)mascari(dot)com>
To: "'Darren King'" <darrenk(at)insightdist(dot)com>, "Pgsql-Hackers(at)Postgresql(dot) Org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: 7.1 pg_dump fails for user-defined types (release stopper?)
Date: 2001-03-30 20:50:02
Message-ID: 01C0B931.15C964B0.mascarm@mascari.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Anything dependent upon the original function in your example is busted 
anyhow, regardless of a dump/reload:

CREATE function test() returns int4 AS 'SELECT 1' LANGUAGE 'SQL';
CREATE

SELECT test()
 test
------
     1
(1 row)

CREATE VIEW test_view AS SELECT test();
CREATE

SELECT * FROM test_view;
 test
------
    1
(1 row)

DROP FUNCTION test();
DROP

CREATE function test() returns int4 AS 'SELECT 1' LANGUAGE 'SQL';
CREATE

SELECT * FROM test_view;
ERROR:  Function OID 387520 does not exist

So dumping OID order is least of the users' problems. Its hard to come up 
with examples where an object dependent upon another in a *working* 
database has a lesser OID. So the regression suite really did its job in 
this case.

Mike Mascari
mascarm(at)mascari(dot)com

-----Original Message-----
From:	Darren King [SMTP:darrenk(at)insightdist(dot)com]
Sent:	Friday, March 30, 2001 3:31 PM
To:	Pgsql-Hackers(at)Postgresql(dot) Org
Subject:	RE: [HACKERS] 7.1 pg_dump fails for user-defined types (release 
stopper?)

> A more promising idea 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.  Or we could try to
> hack pg_dump to fix this, but that doesn't seem
> appetizing.

Requiring OID ordering would open up a new can of worms.

What happens if the user does a drop/create on the function after
creating it?

The function could potentially be recreated with a higher OID and then
the user would be in the same situation.

If the system requires (or works around) creation ordering when creating
functions and types, ISTM that pg_dump should have to do the same.

darrenk


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-03-30 21:05:53
Subject: Re: Re: Changing the default value of an inherited column
Previous:From: Thomas LockhartDate: 2001-03-30 20:46:07
Subject: Re: third call for platforms...

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