Re: Alter or rename enum value

From: Tom Dunstan <pgsql(at)tomd(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Christophe Pettus <xof(at)thebuild(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Alter or rename enum value
Date: 2016-04-05 06:48:24
Message-ID: E520D706-616F-4AD6-98D6-01004AE05317@tomd.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Just stumbled across this thread while looking for something else…

> On 28 Mar 2016, at 12:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> What you really need is to prevent the new value from being inserted
> into any indexes, but checking that directly seems far more difficult,
> ugly, and expensive than the above.
>
> I do not know whether this would be a meaningful improvement for
> common use-cases, though. (It'd help if people were more specific
> about the use-cases they need to work.)

My team’s use case is: We have to add new values to an enum (no removal or renames) during occasional database schema migration as part of software releases. We’re using a db migration tool that understands that postgres can do most schema changes in a transaction, so it attempts to run our add enum value statements in a transaction, even if we mark them as individual changes. With some huffing and puffing we’ve managed to work around this limitation in the tool, but it would definitely be nice to keep our enum-related migrations with our other changes and drop the custom non-transactional migration code that we’ve had to write.

The suggested solution of disallowing any use of the new value during the same transaction that is added in would work fine for us. In the (so far unprecedented) case that we need to use the new value in a migration at the same time, we’d always have the option of splitting the migration up into two transactions.

Cheers

Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2016-04-05 07:03:56 Re: dealing with extension dependencies that aren't quite 'e'
Previous Message Etsuro Fujita 2016-04-05 06:41:00 Re: Odd system-column handling in postgres_fdw join pushdown patch