Re: [PATCH] Alter or rename enum value

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Matthias Kurz <m(dot)kurz(at)irregular(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: [PATCH] Alter or rename enum value
Date: 2016-09-08 09:55:12
Message-ID: CAE2gYzy2U60yhj9fpSciO+cF8AVd2_V++d6GZUiC3NeG8sWwvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Given that you are now familiar with the internals of how enums are
> implemented would it be possible to continue the work and add the "ALTER
> TYPE <name> DROP VALUE <somevalue>" command?

I was thinking to try developing it, but I would be more than happy to
help by testing and reviewing, if someone else would do. I don't
think I have enough experience to think of all details of this
feature.

The main problem that has been discussed before was the indexes. One
way is to tackle with it is to reindex all the tables after the
operation. Currently we are doing it when the datatype of indexed
columns change. So it should be possible, but very expensive.

Another way, Thomas Munro suggested when we were talking about it,
would be to add another column to mark the deleted rows to the catalog
table. We can check for this column before allowing the value to be
used. Indexes can continue using the deleted values. We can also
re-use those entries when someone wants to add new value to the
matching place. It should be safe as long as we don't update the sort
order.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2016-09-08 10:17:07 Re: [sqlsmith] Failed assertion in joinrels.c
Previous Message Pavan Deolasee 2016-09-08 09:35:27 Re: Bug in two-phase transaction recovery