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(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