Comments on: Waiting for 8.4 – pg_conf_load_time, time-related generate_series and enum values in \dT+

By: depesz

depesz — Mon, 05 May 2008 12:01:27 +0000

@Radek Zielinski:
Because pg_enum is in system catalog. I strongly believe that user shouldn’t ever need to touch it.

By: Radek Zielinski

Radek Zielinski — Mon, 05 May 2008 11:25:22 +0000

@depesz: Just out of curiosity, why do you consider an insert to pg_enum (yes, I know it doesn’t solve the sorting problem) unacceptable?

By: depesz

depesz — Mon, 05 May 2008 11:13:50 +0000

@Radek Zielinski:
It’s great to have Your comment here, but trust me – doing “alter table” to fix enum is not acceptable.
It gets exclusive lock on whole table for the time of processing it. Just imagine multi-hour downtime of production site, and You’ll understand why it’s not cool.
There are other ways that “work” as well – like modifying pg_catalog, but it’s also not acceptable in production environment.

By: Radek Zielinski

Radek Zielinski — Mon, 05 May 2008 11:05:27 +0000

@depesz: “until there will be sane way to add and remove elements from ENUM – functionality of this data type is very limited. So limited that I honestly can’t imagine myself any situation in which I would use it.”

You can create a new enum type and cast your columns to it (and recreate any functions using this type, which might get ugly).

create type e1 as enum (‘a’, ‘b’, ‘foo’);
create type e2 as enum (‘a’, ‘b’, ‘c’, ‘bar’);
create table x ( col e1 );
alter table x alter column col type e2 using col::text::e2;

…and will correctly blow up if the data doesn’t fit the second enum (ie, if you have any ‘foo’ values there).

Maybe not the prettiest solution, but works.

By: Thormick

Thormick — Mon, 05 May 2008 08:24:36 +0000

The second patch is very nice to have. Since 8.0 I’ve been declaring such functions manually when I’ve needed them, and it always seemed to be something that should have been included in Pg as standard.