Re: Removing pg_migrator limitations

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

In response to

Responses

Browse pgsql-hackers by date

  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?