From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Maksim Kita <kitaetoya(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Allow deleting enum value |
Date: | 2020-10-26 00:33:04 |
Message-ID: | 20201026003303.GO9241@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 07, 2020 at 11:47:07PM +0300, Maksim Kita wrote:
> I like the idea, during prototype I added additional column and modified
> enum_in method. But enum_in is called in contexts that can be important
> for user (like comparisons).
...
> postgres=# ALTER TYPE test_enum DELETE VALUE '2';
> ALTER TYPE
I think it should be called "DROP VALUE"
> postgres=# SELECT * FROM test_table WHERE value = '2';
> ERROR: enum value is dropped test_enum: "2"
> LINE 1: SELECT * FROM test_table WHERE value = '2';
This fails if the value was never added, so why wouldn't it also fail if the
value is added and then removed ?
Maybe you'd want to rename old enum names to something "unlikely", like what we
do for dropped attributes in RemoveAttributeById.
How do you want to handle "adding a value back" ?
I think you should determine/propose/discuss the desired behaviors before
implementing it.
I think you'd also need to update these:
src/bin/pg_dump/pg_dump.c
src/bin/psql/describe.c
src/bin/psql/tab-complete.c
doc/src/sgml/catalogs.sgml
src/test/regress/sql/enum.sql
src/test/regress/expected/enum.out
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-10-26 00:51:41 | Re: Mop-up around psql's \connect behavior |
Previous Message | Thomas Munro | 2020-10-25 22:48:03 | Re: POC: contrib/unaccent as IMMUTABLE |