Re: WIP: extensible enums

Andrew Dunstan wrote:
>
>
> 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.

pg_upgrade calls a C API to add labels, but the ability to create an
enum with no labels is supported at the SQL level, as I showed above. I
am not saying we don't need before/after, but I am saying we need the
ability to add labels without using before/after because there are no
labels in an empty enum.

I am not sure what you are arguing for/against. I thought we were
agreed to allow before/after, and no specification too. I am just
pointing out that we need the "no specification" syntax for logical as
well as practical reasons.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +