Re: PG upgrade 14->15 fails - database contains our own extension

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> CREATE CAST (integer AS public.lbuid) WITH FUNCTION
> pg_catalog.int8(integer) AS IMPLICIT;
> CREATE CAST (bigint AS public.lbuid) WITHOUT FUNCTION AS IMPLICIT;
> CREATE CAST (public.lbuid AS bigint) WITHOUT FUNCTION AS IMPLICIT;

> That's not a valid dump ordering, and if I drop the casts and try to
> recreate them that way, it fails in the same way you saw.

> My guess is that this is a bug in Tom's commit
> b55f2b6926556115155930c4b2d006c173f45e65, "Adjust pg_dump's priority
> ordering for casts."

Hmm ... I think it's a very ancient bug that somehow David has avoided
tripping over up to now. Namely, that we require the bigint->lbuid
implicit cast to exist in order to make that WITH FUNCTION cast, but
we fail to record it as a dependency during CastCreate. So pg_dump
is flying blind as to the required restoration order, and if it ever
worked, you were just lucky.

We might be able to put in some kluge in pg_dump to make it less
likely to fail with existing DBs, but I think the true fix lies
in adding that dependency.

(I'm pretty skeptical about it being a good idea to have a set of
casts like this, but I don't suppose pg_dump is chartered to
editorialize on that.)

regards, tom lane