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<j...@agliodbs.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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers