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

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@mascari.com

-----Original Message-----
From:    Darren King [SMTP:darrenk@insightdist.com]
Sent:    Friday, March 30, 2001 3:31 PM
To:    Pgsql-Hackers@Postgresql. 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