From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Removing pg_migrator limitations |
Date: | 2009-12-23 19:53:50 |
Message-ID: | 407d949e0912231153v6d04cbacib28c2f17b99f26fa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-23 19:55:56 | About the CREATE TABLE LIKE indexes vs constraints issue |
Previous Message | Guillaume Smet | 2009-12-23 19:26:18 | Re: creating index names automatically? |