| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | 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:17:32 |
| Message-ID: | 12048.1261595852@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2009-12-23 19:26:18 | Re: creating index names automatically? |
| Previous Message | Tom Lane | 2009-12-23 19:12:36 | Re: Removing pg_migrator limitations |