Re: Alter or rename enum value

From: Matthias Kurz <m(dot)kurz(at)irregular(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Alter or rename enum value
Date: 2016-03-25 08:13:50
Message-ID: CAO=2mx6EOh6uQQ57Kv2z0x=kuyVbkEbwiY8R2h6VCPL=Fxe5wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> It's conceivable that we could do something like adding an "isdead"
> column to pg_enum and making enum_in reject new values that're marked
> isdead. But I can't see that we'd ever be able to support true
> removal of an enum value at reasonable cost. And I'm not really sure
> where the use-case argument is for working hard on it.
>

Thanks for all your explanation!
We work a lot with enums and sometimes there are cases where we would like
to be able to add a new value or rename an existing value (in a new
transaction) - dropping isn't needed that much, but would be a bonus.
Right now you have to know which enum values you will use at the time
creating a table - but as many things change also requirements for a
database/schema/table/enum definition change. At the moment we have to use
ugly hacks to make renaming/dropping work.
I didn't know implementing these features would be that complex. As I am
not familiar with the code and don't have time to dig into it I won't be
able to provide a patch myself unfortunately.
Hopefully at the commitfest at least the transaction limitation will/could
be tackled - that would help us a lot already.

Thanks for your time!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-03-25 08:16:21 Re: Odd system-column handling in postgres_fdw join pushdown patch
Previous Message Thomas Munro 2016-03-25 07:51:46 Re: Proposal: "Causal reads" mode for load balancing reads without stale data