Re: WIP: extensible enums

On 08/23/2010 07:12 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> On 8/23/10 12:20 PM, Tom Lane wrote:
>>> Josh Berkus<josh(at)agliodbs(dot)com> writes:
>>>> I really don't see the value in making a command substantially less
>>>> intuitive in order to avoid a single keyword, unless it affects areas of
>>>> Postgres outside of this particular command.
>>> It's the three variants to do two things that I find unintuitive.
>> Actually, it's 3 different things:
>>
>> 1. BEFORE adds a value before the value cited.
>> 2. AFTER adds a value after the value cited.
>> 3. unqualified adds a value at the end.
>>
>> The fact that AFTER allows you to add a value at the end is
>> circumstantial overlap. While executing an AFTER, you wouldn't *know*
>> that you were adding it to the end, necessarily.
>>
>> The other reason to have AFTER is that, in scripts, the user may not
>> have the before value handy due to context (i.e. dynamically building an
>> enum).
>>
>> Anyway, this'll still be useful with BEFORE only. I'm just convinced
>> that we'll end up adding AFTER in 9.2 or 9.3 after we get a bunch of
>> user complaints and questions. So why not add it now?
> CREATE ENUM in PG 9.0 allows you to create an enum with no columns,
> e.g.:
>
> test=> CREATE TYPE etest AS ENUM ();
> CREATE TYPE
>
> so I think we have to have the ability add an enum without a
> before/after. This ability was added for pg_upgrade.
>

No we don't. pg_upgrade calls a C function. There is no support for this
at the SQL level AIUI. And the ability to add labels at arbitrary
positions in the sort order is an essential part of this feature.

cheers

andrew