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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
