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 по дате отправления: