Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
Date
Msg-id 19241.1341248511@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created  (Bruce Momjian <bruce@momjian.us>)
Responses Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
List pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
> +
> +         /*
> +          *    We unconditionally create the extension, so we must drop it if it
> +          *    exists.  This could happen if the user deleted 'plpgsql' and then
> +          *    readded it, causing its oid to be greater than FirstNormalObjectId.
> +          */
> +         appendPQExpBuffer(q, "DROP EXTENSION IF EXISTS %s;\n", qextname);

This doesn't seem like anything but a wart :-(.  It's unlike the
behavior for every other kind of object, it introduces the inconsistent
behavior even in non-binary-upgrade cases, and it does nothing at all to
address the points I made about reproducing the previous state in cases
where the admin removed the language or changed its permissions.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created