Re: Removing pg_migrator limitations

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Removing pg_migrator limitations
Дата
Msg-id 407d949e0912231153v6d04cbacib28c2f17b99f26fa@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing pg_migrator limitations  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Removing pg_migrator limitations
Список pgsql-hackers
On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> The remaining issue is pg_enum oids.  Because it will be difficult to
>> pass an arbitrary number of oids into the backend, the idea was to
>> assign each enum value separately.  If we implement this TODO item:
>
>>       Allow adding/renaming/removing enumerated values to an existing
>>       enumerated data type
>
> The reason that isn't implemented is that it's *hard* --- in fact,
> it appears to be entirely impossible in the general case, unless you're
> willing to change existing values of the enum on-disk.  I do not agree
> that it's a good plan to try to solve that as a prerequisite to making
> pg_migrator work.

Shouldn't adding new ones be easy? As long as we're willing to make it
fail with an error if there's a conflict -- which is sufficient for
pg_dump's needs.

--
greg


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

Предыдущее
От: Guillaume Smet
Дата:
Сообщение: Re: creating index names automatically?
Следующее
От: Tom Lane
Дата:
Сообщение: About the CREATE TABLE LIKE indexes vs constraints issue