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