Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
Дата
Msg-id CAAZKuFbAeFF9v9BuvGkdN2rGz7iU29cY+Nb++z3tvX3vtU-CPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-bugs
On Tue, Jul 10, 2012 at 2:43 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Jul 10, 2012 at 01:03:18PM -0700, Maciek Sakrejda wrote:
>> So, is there hope of a better fix here for 9.2 (specifically for
>> preserving extension ownership on pg_upgrade and dump/restore, though
>> I understand it may not make sense to do that if we can't fix a number
>> of related issues)? If not, is the below catalog-twiddling sane,
>> lacking an ALTER EXTENSION foo OWNER TO ...?
>>
>> postgres=# update pg_extension set extowner = (select oid from
>> pg_roles where rolname = 'maciek') where extname = 'plpgsql';
>
> There is no hope that any changes to extensions will be preserved across
> upgrades any better than it was in 9.1 --- the change is only that
> pg_upgrade will not fail.

Even in the absence of preservation, the problem is there doesn't seem
to be a way to re-seat the extension into the correct, previous
configuration either.  One can't just DROP CASCADE plpgsql, lest
existing UDFs depend up on them, and one can't reassign the owner
in-place either to fix the situation.  Except, maybe, via this catalog
hack.

--
fdr

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #6706: pg_upgrade fails when plpgsql dropped/re-created
Следующее
От: Christian Ullrich
Дата:
Сообщение: pg_basebackup de.po: Wrong translation