Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
От | Tom Lane |
---|---|
Тема | Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created |
Дата | |
Msg-id | 19241.1341248511@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: BUG #6706: pg_upgrade fails when plpgsql
dropped/re-created
|
Список | 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 по дате отправления: