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

Tricia Holben of Great Bridge just pointed out to me a rather nasty
problem that's exposed by trying to pg_dump and reload the regression
test database. The regression tests include

CREATE FUNCTION widget_in(opaque)
RETURNS widget
AS '/home/postgres/pgsql/src/test/regress/regress.sl'
LANGUAGE 'c';
NOTICE: ProcedureCreate: type 'widget' is not yet defined

CREATE FUNCTION widget_out(opaque)
RETURNS opaque
AS '/home/postgres/pgsql/src/test/regress/regress.sl'
LANGUAGE 'c';

CREATE TYPE widget (
internallength = 24,
input = widget_in,
output = widget_out,
alignment = double
);

which is considered a correct approach to defining I/O procedures for
user-defined types; notice that the code goes out of its way to allow
type "widget" to be referenced before it is defined.

Unfortunately, since the shell pg_type entry for type widget is created
before the pg_proc entry for widget_in is, the OID assignment sequence
is: widget, widget_in, widget_out. When pg_dump dumps these objects in
OID order, it dumps the CREATE TYPE command first --- an ordering that
will fail upon reload.

7.0.* and before do not have this problem because they dump type
definitions after function definitions, regardless of OIDs.

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
break people's 7.0 dump scripts all by itself. 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.

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.

regards, tom lane