add label to enum syntax
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
That way if we later wanted to support some other sort of ADD operation
on types we would be able to more easily. LABEL is already a keyword, so
it should be pretty minimally invasive to make this change, and if we
want to do it now is the time.
Thoughts?
cheers
andrew
2010/10/25 Andrew Dunstan <andrew@dunslane.net>:
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
+1
Regards
Pavel
Show quoted text
That way if we later wanted to support some other sort of ADD operation on
types we would be able to more easily. LABEL is already a keyword, so it
should be pretty minimally invasive to make this change, and if we want to
do it now is the time.Thoughts?
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
On Mon, Oct 25, 2010 at 11:57 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2010/10/25 Andrew Dunstan <andrew@dunslane.net>:
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
+1
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On mån, 2010-10-25 at 11:48 -0400, Andrew Dunstan wrote:
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
That had occurred to me as well. Go for it.
Andrew Dunstan <andrew@dunslane.net> writes:
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
That way if we later wanted to support some other sort of ADD operation
on types we would be able to more easily.
I can see the point of that, but I don't find LABEL to be a particularly
great name for the elements of an enum type, and so I'm not in favor of
institutionalizing that name in the syntax. How about ADD VALUE?
regards, tom lane
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
I can see the point of that, but I don't find LABEL to be a particularly
great name for the elements of an enum type, and so I'm not in favor of
institutionalizing that name in the syntax. How about ADD VALUE?
From the fine manual:
The second form of CREATE TYPE creates an enumerated (enum) type, as described in Section 8.7. Enum types take a list of one or more quoted labels, each of which must be less than NAMEDATALEN bytes long (64 in a standard PostgreSQL build).
So the docs have called them "labels" for quite some time.
David
"David E. Wheeler" <david@kineticode.com> writes:
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
I can see the point of that, but I don't find LABEL to be a particularly
great name for the elements of an enum type, and so I'm not in favor of
institutionalizing that name in the syntax. How about ADD VALUE?
So the docs have called them "labels" for quite some time.
There are some places in the docs that use that term, but there are
others that don't. In any case, using the term in the SQL syntax
casts it in stone, not silly putty ...
regards, tom lane
On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David E. Wheeler" <david@kineticode.com> writes:
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
I can see the point of that, but I don't find LABEL to be a particularly
great name for the elements of an enum type, and so I'm not in favor of
institutionalizing that name in the syntax. How about ADD VALUE?So the docs have called them "labels" for quite some time.
There are some places in the docs that use that term, but there are
others that don't. In any case, using the term in the SQL syntax
casts it in stone, not silly putty ...
Personally, I prefer LABEL. But I could live with VALUE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 10/25/2010 02:51 PM, Robert Haas wrote:
On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
"David E. Wheeler"<david@kineticode.com> writes:
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
I can see the point of that, but I don't find LABEL to be a particularly
great name for the elements of an enum type, and so I'm not in favor of
institutionalizing that name in the syntax. How about ADD VALUE?So the docs have called them "labels" for quite some time.
There are some places in the docs that use that term, but there are
others that don't. In any case, using the term in the SQL syntax
casts it in stone, not silly putty ...Personally, I prefer LABEL. But I could live with VALUE.
That's roughly my position. It would be consistent with the name we use
in the catalogs, as well as what's in the docs. I don't think it's as
opaque as Tom seems to suggest. An enum is pretty much an ordered set of
labels. But I could certainly live with VALUE if that's the consensus.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> wrote:
Personally, I prefer LABEL. But I could live with VALUE.
That's roughly my position.
LABEL would seem more natural to me. I would tend to think of the
VALUE as the hidden number which determines the order.
-Kevin
2010/10/25 Andrew Dunstan <andrew@dunslane.net>:
On 10/25/2010 02:51 PM, Robert Haas wrote:
On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
"David E. Wheeler"<david@kineticode.com> writes:
On Oct 25, 2010, at 10:08 AM, Tom Lane wrote:
I can see the point of that, but I don't find LABEL to be a
particularly
great name for the elements of an enum type, and so I'm not in favor of
institutionalizing that name in the syntax. How about ADD VALUE?So the docs have called them "labels" for quite some time.
There are some places in the docs that use that term, but there are
others that don't. In any case, using the term in the SQL syntax
casts it in stone, not silly putty ...Personally, I prefer LABEL. But I could live with VALUE.
That's roughly my position. It would be consistent with the name we use in
the catalogs, as well as what's in the docs. I don't think it's as opaque as
Tom seems to suggest. An enum is pretty much an ordered set of labels. But I
could certainly live with VALUE if that's the consensus.
I agree with you. There are some better keywords than VALUE - maybe
ELEMENT or just LABEL. I understand if there must be a reserved
keyword - but if not I prefer LABEL too.
Regards
Pavel
Show quoted text
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
On 10/25/2010 04:03 PM, Pavel Stehule wrote:
2010/10/25 Andrew Dunstan<andrew@dunslane.net>:
On 10/25/2010 02:51 PM, Robert Haas wrote:
Personally, I prefer LABEL. But I could live with VALUE.
That's roughly my position. It would be consistent with the name we use in
the catalogs, as well as what's in the docs. I don't think it's as opaque as
Tom seems to suggest. An enum is pretty much an ordered set of labels. But I
could certainly live with VALUE if that's the consensus.I agree with you. There are some better keywords than VALUE - maybe
ELEMENT or just LABEL. I understand if there must be a reserved
keyword - but if not I prefer LABEL too.
LABEL is already an unreserved keyword, and I'm pretty sure that's all
we'll need.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
LABEL is already an unreserved keyword, and I'm pretty sure that's all
we'll need.
The only reason it's a keyword is the SECURITY LABEL patch that went
in a month or so ago; which is syntax that might still be thought
better of before it gets to a release.
But I seem to be in the minority, so I'll shut up now.
regards, tom lane
On 25 October 2010 21:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
LABEL is already an unreserved keyword, and I'm pretty sure that's all
we'll need.The only reason it's a keyword is the SECURITY LABEL patch that went
in a month or so ago; which is syntax that might still be thought
better of before it gets to a release.But I seem to be in the minority, so I'll shut up now.
regards, tom lane
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
"element", so how about ADD ELEMENT?
The label is just one of the ways of identifying the element, and the
value is element's OID. The thing you're adding is an element, with
both a label and a value.
Regards,
Dean
Show quoted text
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/26/2010 03:02 AM, Dean Rasheed wrote:
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
"element", so how about ADD ELEMENT?
Unlike the other suggestions, ELEMENT is not currently a keyword. That
doesn't rule it out entirely, but it's a factor worth consideration.
The label is just one of the ways of identifying the element, and the
value is element's OID. The thing you're adding is an element, with
both a label and a value.
No, I think that's the wrong way of thinking about it entirely. The
label *is* the value and the OID is simply an implementation detail,
which for the most part we keep completely hidden from the user. We
could have implemented enums in ways that did not involve OIDs at all,
with identical semantics.
Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
cheers
andrew
On Tue, Oct 26, 2010 at 9:54 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 10/26/2010 03:02 AM, Dean Rasheed wrote:
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
"element", so how about ADD ELEMENT?Unlike the other suggestions, ELEMENT is not currently a keyword. That
doesn't rule it out entirely, but it's a factor worth consideration.The label is just one of the ways of identifying the element, and the
value is element's OID. The thing you're adding is an element, with
both a label and a value.No, I think that's the wrong way of thinking about it entirely. The label
*is* the value and the OID is simply an implementation detail, which for the
most part we keep completely hidden from the user. We could have implemented
enums in ways that did not involve OIDs at all, with identical semantics.Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
I still think we should just go for LABEL and be done with it. But
y'all can ignore me if you want...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Excerpts from Andrew Dunstan's message of mar oct 26 10:54:59 -0300 2010:
On 10/26/2010 03:02 AM, Dean Rasheed wrote:
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
"element", so how about ADD ELEMENT?Unlike the other suggestions, ELEMENT is not currently a keyword. That
doesn't rule it out entirely, but it's a factor worth consideration.
It can be added as an unreserved keyword, as in the attached patch.
I also like ELEMENT better than the other suggestions, so I'm gonna
commit this unless there are objections.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Attachments:
0001-Change-syntax-to-add-a-new-enum-value-to-ALTER-TYPE-.patchapplication/octet-stream; name=0001-Change-syntax-to-add-a-new-enum-value-to-ALTER-TYPE-.patchDownload
From 5187deb2db0edf4b0823f5d9102f34f501b9b2f1 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Tue, 26 Oct 2010 11:40:06 -0300
Subject: [PATCH] Change syntax to add a new enum value to ALTER TYPE ADD ELEMENT
Per discussion.
---
doc/src/sgml/ref/alter_type.sgml | 8 ++--
src/backend/parser/gram.y | 19 +++++----
src/include/parser/kwlist.h | 1 +
src/test/regress/expected/enum.out | 74 ++++++++++++++++++------------------
src/test/regress/sql/enum.sql | 74 ++++++++++++++++++------------------
5 files changed, 89 insertions(+), 87 deletions(-)
diff --git a/doc/src/sgml/ref/alter_type.sgml b/doc/src/sgml/ref/alter_type.sgml
index 90de2e8..1fbade1 100644
--- a/doc/src/sgml/ref/alter_type.sgml
+++ b/doc/src/sgml/ref/alter_type.sgml
@@ -28,7 +28,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> OWNER TO <replaceab
ALTER TYPE <replaceable class="PARAMETER">name</replaceable> RENAME ATTRIBUTE <replaceable class="PARAMETER">attribute_name</replaceable> TO <replaceable class="PARAMETER">new_attribute_name</replaceable>
ALTER TYPE <replaceable class="PARAMETER">name</replaceable> RENAME TO <replaceable class="PARAMETER">new_name</replaceable>
ALTER TYPE <replaceable class="PARAMETER">name</replaceable> SET SCHEMA <replaceable class="PARAMETER">new_schema</replaceable>
-ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD <replaceable class="PARAMETER">new_enum_value</replaceable> [ { BEFORE | AFTER } <replaceable class="PARAMETER">existing_enum_value</replaceable> ]
+ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD ELEMENT <replaceable class="PARAMETER">new_enum_value</replaceable> [ { BEFORE | AFTER } <replaceable class="PARAMETER">existing_enum_value</replaceable> ]
<phrase>where <replaceable class="PARAMETER">action</replaceable> is one of:</phrase>
@@ -106,7 +106,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD <replaceable cl
</varlistentry>
<varlistentry>
- <term><literal>ADD [ BEFORE | AFTER ]</literal></term>
+ <term><literal>ADD ELEMENT [ BEFORE | AFTER ]</literal></term>
<listitem>
<para>
This form adds a new value to an enum type. If the new value's place in
@@ -238,7 +238,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD <replaceable cl
<title>Notes</title>
<para>
- <command>ALTER TYPE ... ADD</> (the form that adds a new value to an
+ <command>ALTER TYPE ... ADD ELEMENT</> (the form that adds a new value to an
enum type) cannot be executed inside a transaction block.
</para>
@@ -292,7 +292,7 @@ ALTER TYPE compfoo ADD ATTRIBUTE f3 int;
<para>
To add a new value to an enum type in a particular sort position:
<programlisting>
-ALTER TYPE colors ADD 'orange' AFTER 'red';
+ALTER TYPE colors ADD ELEMENT 'orange' AFTER 'red';
</programlisting>
</para>
</refsect1>
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 1394b21..287ff20 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -483,7 +483,7 @@ static RangeVar *makeRangeVarFromAnyName(List *names, int position, core_yyscan_
DEFERRABLE DEFERRED DEFINER DELETE_P DELIMITER DELIMITERS DESC
DICTIONARY DISABLE_P DISCARD DISTINCT DO DOCUMENT_P DOMAIN_P DOUBLE_P DROP
- EACH ELSE ENABLE_P ENCODING ENCRYPTED END_P ENUM_P ESCAPE EXCEPT
+ EACH ELEMENT ELSE ENABLE_P ENCODING ENCRYPTED END_P ENUM_P ESCAPE EXCEPT
EXCLUDE EXCLUDING EXCLUSIVE EXECUTE EXISTS EXPLAIN EXTERNAL EXTRACT
FALSE_P FAMILY FETCH FIRST_P FLOAT_P FOLLOWING FOR FORCE FOREIGN FORWARD
@@ -3871,30 +3871,30 @@ enum_val_list: Sconst
*****************************************************************************/
AlterEnumStmt:
- ALTER TYPE_P any_name ADD_P Sconst
+ ALTER TYPE_P any_name ADD_P ELEMENT Sconst
{
AlterEnumStmt *n = makeNode(AlterEnumStmt);
n->typeName = $3;
- n->newVal = $5;
+ n->newVal = $6;
n->newValNeighbor = NULL;
n->newValIsAfter = true;
$$ = (Node *) n;
}
- | ALTER TYPE_P any_name ADD_P Sconst BEFORE Sconst
+ | ALTER TYPE_P any_name ADD_P ELEMENT Sconst BEFORE Sconst
{
AlterEnumStmt *n = makeNode(AlterEnumStmt);
n->typeName = $3;
- n->newVal = $5;
- n->newValNeighbor = $7;
+ n->newVal = $6;
+ n->newValNeighbor = $8;
n->newValIsAfter = false;
$$ = (Node *) n;
}
- | ALTER TYPE_P any_name ADD_P Sconst AFTER Sconst
+ | ALTER TYPE_P any_name ADD_P ELEMENT Sconst AFTER Sconst
{
AlterEnumStmt *n = makeNode(AlterEnumStmt);
n->typeName = $3;
- n->newVal = $5;
- n->newValNeighbor = $7;
+ n->newVal = $6;
+ n->newValNeighbor = $8;
n->newValIsAfter = true;
$$ = (Node *) n;
}
@@ -11141,6 +11141,7 @@ unreserved_keyword:
| DOUBLE_P
| DROP
| EACH
+ | ELEMENT
| ENABLE_P
| ENCODING
| ENCRYPTED
diff --git a/src/include/parser/kwlist.h b/src/include/parser/kwlist.h
index 2c44cf7..f1bd388 100644
--- a/src/include/parser/kwlist.h
+++ b/src/include/parser/kwlist.h
@@ -136,6 +136,7 @@ PG_KEYWORD("domain", DOMAIN_P, UNRESERVED_KEYWORD)
PG_KEYWORD("double", DOUBLE_P, UNRESERVED_KEYWORD)
PG_KEYWORD("drop", DROP, UNRESERVED_KEYWORD)
PG_KEYWORD("each", EACH, UNRESERVED_KEYWORD)
+PG_KEYWORD("element", ELEMENT, UNRESERVED_KEYWORD)
PG_KEYWORD("else", ELSE, RESERVED_KEYWORD)
PG_KEYWORD("enable", ENABLE_P, UNRESERVED_KEYWORD)
PG_KEYWORD("encoding", ENCODING, UNRESERVED_KEYWORD)
diff --git a/src/test/regress/expected/enum.out b/src/test/regress/expected/enum.out
index b1ba3f1..9f1faed 100644
--- a/src/test/regress/expected/enum.out
+++ b/src/test/regress/expected/enum.out
@@ -39,7 +39,7 @@ ORDER BY 2;
mars | 3
(3 rows)
-ALTER TYPE planets ADD 'uranus';
+ALTER TYPE planets ADD ELEMENT 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
WHERE enumtypid = 'planets'::regtype
@@ -52,10 +52,10 @@ ORDER BY 2;
uranus | 4
(4 rows)
-ALTER TYPE planets ADD 'mercury' BEFORE 'venus';
-ALTER TYPE planets ADD 'saturn' BEFORE 'uranus';
-ALTER TYPE planets ADD 'jupiter' AFTER 'mars';
-ALTER TYPE planets ADD 'neptune' AFTER 'uranus';
+ALTER TYPE planets ADD ELEMENT 'mercury' BEFORE 'venus';
+ALTER TYPE planets ADD ELEMENT 'saturn' BEFORE 'uranus';
+ALTER TYPE planets ADD ELEMENT 'jupiter' AFTER 'mars';
+ALTER TYPE planets ADD ELEMENT 'neptune' AFTER 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
WHERE enumtypid = 'planets'::regtype
@@ -89,46 +89,46 @@ ORDER BY enumlabel::planets;
(8 rows)
-- errors for adding labels
-ALTER TYPE planets ADD
+ALTER TYPE planets ADD ELEMENT
'plutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutopluto';
ERROR: invalid enum label "plutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutopluto"
DETAIL: Labels must be 63 characters or less.
-ALTER TYPE planets ADD 'pluto' AFTER 'zeus';
+ALTER TYPE planets ADD ELEMENT 'pluto' AFTER 'zeus';
ERROR: "zeus" is not an existing enum label
--
-- Test inserting so many values that we have to renumber
--
create type insenum as enum ('L1', 'L2');
-alter type insenum add 'i1' before 'L2';
-alter type insenum add 'i2' before 'L2';
-alter type insenum add 'i3' before 'L2';
-alter type insenum add 'i4' before 'L2';
-alter type insenum add 'i5' before 'L2';
-alter type insenum add 'i6' before 'L2';
-alter type insenum add 'i7' before 'L2';
-alter type insenum add 'i8' before 'L2';
-alter type insenum add 'i9' before 'L2';
-alter type insenum add 'i10' before 'L2';
-alter type insenum add 'i11' before 'L2';
-alter type insenum add 'i12' before 'L2';
-alter type insenum add 'i13' before 'L2';
-alter type insenum add 'i14' before 'L2';
-alter type insenum add 'i15' before 'L2';
-alter type insenum add 'i16' before 'L2';
-alter type insenum add 'i17' before 'L2';
-alter type insenum add 'i18' before 'L2';
-alter type insenum add 'i19' before 'L2';
-alter type insenum add 'i20' before 'L2';
-alter type insenum add 'i21' before 'L2';
-alter type insenum add 'i22' before 'L2';
-alter type insenum add 'i23' before 'L2';
-alter type insenum add 'i24' before 'L2';
-alter type insenum add 'i25' before 'L2';
-alter type insenum add 'i26' before 'L2';
-alter type insenum add 'i27' before 'L2';
-alter type insenum add 'i28' before 'L2';
-alter type insenum add 'i29' before 'L2';
-alter type insenum add 'i30' before 'L2';
+alter type insenum add element 'i1' before 'L2';
+alter type insenum add element 'i2' before 'L2';
+alter type insenum add element 'i3' before 'L2';
+alter type insenum add element 'i4' before 'L2';
+alter type insenum add element 'i5' before 'L2';
+alter type insenum add element 'i6' before 'L2';
+alter type insenum add element 'i7' before 'L2';
+alter type insenum add element 'i8' before 'L2';
+alter type insenum add element 'i9' before 'L2';
+alter type insenum add element 'i10' before 'L2';
+alter type insenum add element 'i11' before 'L2';
+alter type insenum add element 'i12' before 'L2';
+alter type insenum add element 'i13' before 'L2';
+alter type insenum add element 'i14' before 'L2';
+alter type insenum add element 'i15' before 'L2';
+alter type insenum add element 'i16' before 'L2';
+alter type insenum add element 'i17' before 'L2';
+alter type insenum add element 'i18' before 'L2';
+alter type insenum add element 'i19' before 'L2';
+alter type insenum add element 'i20' before 'L2';
+alter type insenum add element 'i21' before 'L2';
+alter type insenum add element 'i22' before 'L2';
+alter type insenum add element 'i23' before 'L2';
+alter type insenum add element 'i24' before 'L2';
+alter type insenum add element 'i25' before 'L2';
+alter type insenum add element 'i26' before 'L2';
+alter type insenum add element 'i27' before 'L2';
+alter type insenum add element 'i28' before 'L2';
+alter type insenum add element 'i29' before 'L2';
+alter type insenum add element 'i30' before 'L2';
-- The exact values of enumsortorder will now depend on the local properties
-- of float4, but in any reasonable implementation we should get at least
-- 20 splits before having to renumber; so only hide values > 20.
diff --git a/src/test/regress/sql/enum.sql b/src/test/regress/sql/enum.sql
index 70bf8c5..2d24038 100644
--- a/src/test/regress/sql/enum.sql
+++ b/src/test/regress/sql/enum.sql
@@ -26,17 +26,17 @@ FROM pg_enum
WHERE enumtypid = 'planets'::regtype
ORDER BY 2;
-ALTER TYPE planets ADD 'uranus';
+ALTER TYPE planets ADD ELEMENT 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
WHERE enumtypid = 'planets'::regtype
ORDER BY 2;
-ALTER TYPE planets ADD 'mercury' BEFORE 'venus';
-ALTER TYPE planets ADD 'saturn' BEFORE 'uranus';
-ALTER TYPE planets ADD 'jupiter' AFTER 'mars';
-ALTER TYPE planets ADD 'neptune' AFTER 'uranus';
+ALTER TYPE planets ADD ELEMENT 'mercury' BEFORE 'venus';
+ALTER TYPE planets ADD ELEMENT 'saturn' BEFORE 'uranus';
+ALTER TYPE planets ADD ELEMENT 'jupiter' AFTER 'mars';
+ALTER TYPE planets ADD ELEMENT 'neptune' AFTER 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
@@ -49,10 +49,10 @@ WHERE enumtypid = 'planets'::regtype
ORDER BY enumlabel::planets;
-- errors for adding labels
-ALTER TYPE planets ADD
+ALTER TYPE planets ADD ELEMENT
'plutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutopluto';
-ALTER TYPE planets ADD 'pluto' AFTER 'zeus';
+ALTER TYPE planets ADD ELEMENT 'pluto' AFTER 'zeus';
--
-- Test inserting so many values that we have to renumber
@@ -60,36 +60,36 @@ ALTER TYPE planets ADD 'pluto' AFTER 'zeus';
create type insenum as enum ('L1', 'L2');
-alter type insenum add 'i1' before 'L2';
-alter type insenum add 'i2' before 'L2';
-alter type insenum add 'i3' before 'L2';
-alter type insenum add 'i4' before 'L2';
-alter type insenum add 'i5' before 'L2';
-alter type insenum add 'i6' before 'L2';
-alter type insenum add 'i7' before 'L2';
-alter type insenum add 'i8' before 'L2';
-alter type insenum add 'i9' before 'L2';
-alter type insenum add 'i10' before 'L2';
-alter type insenum add 'i11' before 'L2';
-alter type insenum add 'i12' before 'L2';
-alter type insenum add 'i13' before 'L2';
-alter type insenum add 'i14' before 'L2';
-alter type insenum add 'i15' before 'L2';
-alter type insenum add 'i16' before 'L2';
-alter type insenum add 'i17' before 'L2';
-alter type insenum add 'i18' before 'L2';
-alter type insenum add 'i19' before 'L2';
-alter type insenum add 'i20' before 'L2';
-alter type insenum add 'i21' before 'L2';
-alter type insenum add 'i22' before 'L2';
-alter type insenum add 'i23' before 'L2';
-alter type insenum add 'i24' before 'L2';
-alter type insenum add 'i25' before 'L2';
-alter type insenum add 'i26' before 'L2';
-alter type insenum add 'i27' before 'L2';
-alter type insenum add 'i28' before 'L2';
-alter type insenum add 'i29' before 'L2';
-alter type insenum add 'i30' before 'L2';
+alter type insenum add element 'i1' before 'L2';
+alter type insenum add element 'i2' before 'L2';
+alter type insenum add element 'i3' before 'L2';
+alter type insenum add element 'i4' before 'L2';
+alter type insenum add element 'i5' before 'L2';
+alter type insenum add element 'i6' before 'L2';
+alter type insenum add element 'i7' before 'L2';
+alter type insenum add element 'i8' before 'L2';
+alter type insenum add element 'i9' before 'L2';
+alter type insenum add element 'i10' before 'L2';
+alter type insenum add element 'i11' before 'L2';
+alter type insenum add element 'i12' before 'L2';
+alter type insenum add element 'i13' before 'L2';
+alter type insenum add element 'i14' before 'L2';
+alter type insenum add element 'i15' before 'L2';
+alter type insenum add element 'i16' before 'L2';
+alter type insenum add element 'i17' before 'L2';
+alter type insenum add element 'i18' before 'L2';
+alter type insenum add element 'i19' before 'L2';
+alter type insenum add element 'i20' before 'L2';
+alter type insenum add element 'i21' before 'L2';
+alter type insenum add element 'i22' before 'L2';
+alter type insenum add element 'i23' before 'L2';
+alter type insenum add element 'i24' before 'L2';
+alter type insenum add element 'i25' before 'L2';
+alter type insenum add element 'i26' before 'L2';
+alter type insenum add element 'i27' before 'L2';
+alter type insenum add element 'i28' before 'L2';
+alter type insenum add element 'i29' before 'L2';
+alter type insenum add element 'i30' before 'L2';
-- The exact values of enumsortorder will now depend on the local properties
-- of float4, but in any reasonable implementation we should get at least
--
1.7.1
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Andrew Dunstan's message of mar oct 26 10:54:59 -0300 2010:
Unlike the other suggestions, ELEMENT is not currently a keyword. That
doesn't rule it out entirely, but it's a factor worth consideration.
It can be added as an unreserved keyword, as in the attached patch.
I also like ELEMENT better than the other suggestions, so I'm gonna
commit this unless there are objections.
I definitely vote *against* adding a new keyword for this, unreserved or
otherwise. Every keyword we add bloats the bison parser by some
fractional amount, costing performance across the board.
While I'm not very thrilled with LABEL, it at least has the virtue that
we already paid the price for it.
regards, tom lane
On Oct 26, 2010, at 7:15 AM, Robert Haas wrote:
Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
I still think we should just go for LABEL and be done with it. But
y'all can ignore me if you want...
+1
David
On 26 October 2010 17:04, David E. Wheeler <david@kineticode.com> wrote:
On Oct 26, 2010, at 7:15 AM, Robert Haas wrote:
Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
I still think we should just go for LABEL and be done with it. But
y'all can ignore me if you want...+1
Well ELEMENT is a reserved keyword in SQL:2008, to support multisets,
so if we ever supported that feature...
But I don't feel strongly about this. I think the overall consensus so
far is in favour of LABEL.
Regards,
Dean
Excerpts from Dean Rasheed's message of mar oct 26 15:46:56 -0300 2010:
On 26 October 2010 17:04, David E. Wheeler <david@kineticode.com> wrote:
On Oct 26, 2010, at 7:15 AM, Robert Haas wrote:
Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
I still think we should just go for LABEL and be done with it. But
y'all can ignore me if you want...+1
Well ELEMENT is a reserved keyword in SQL:2008, to support multisets,
so if we ever supported that feature...
Hah!
Well, here's a patch for LABEL in any case. If we're going to have to
reserve ELEMENT in the future then there doesn't seem to be much point
in not choosing that one though. Should we take a poll?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Attachments:
0001-Change-syntax-to-add-a-new-enum-value-to-ALTER-TYPE-.patchapplication/octet-stream; name=0001-Change-syntax-to-add-a-new-enum-value-to-ALTER-TYPE-.patchDownload
From 106f8259d34a40294217f2a6e511d869c7d0c959 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Tue, 26 Oct 2010 11:40:06 -0300
Subject: [PATCH] Change syntax to add a new enum value to ALTER TYPE ADD LABEL
Per discussion.
---
doc/src/sgml/ref/alter_type.sgml | 8 ++--
src/backend/parser/gram.y | 16 ++++----
src/test/regress/expected/enum.out | 74 ++++++++++++++++++------------------
src/test/regress/sql/enum.sql | 74 ++++++++++++++++++------------------
4 files changed, 86 insertions(+), 86 deletions(-)
diff --git a/doc/src/sgml/ref/alter_type.sgml b/doc/src/sgml/ref/alter_type.sgml
index 90de2e8..13c39f9 100644
--- a/doc/src/sgml/ref/alter_type.sgml
+++ b/doc/src/sgml/ref/alter_type.sgml
@@ -28,7 +28,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> OWNER TO <replaceab
ALTER TYPE <replaceable class="PARAMETER">name</replaceable> RENAME ATTRIBUTE <replaceable class="PARAMETER">attribute_name</replaceable> TO <replaceable class="PARAMETER">new_attribute_name</replaceable>
ALTER TYPE <replaceable class="PARAMETER">name</replaceable> RENAME TO <replaceable class="PARAMETER">new_name</replaceable>
ALTER TYPE <replaceable class="PARAMETER">name</replaceable> SET SCHEMA <replaceable class="PARAMETER">new_schema</replaceable>
-ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD <replaceable class="PARAMETER">new_enum_value</replaceable> [ { BEFORE | AFTER } <replaceable class="PARAMETER">existing_enum_value</replaceable> ]
+ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD LABEL <replaceable class="PARAMETER">new_enum_value</replaceable> [ { BEFORE | AFTER } <replaceable class="PARAMETER">existing_enum_value</replaceable> ]
<phrase>where <replaceable class="PARAMETER">action</replaceable> is one of:</phrase>
@@ -106,7 +106,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD <replaceable cl
</varlistentry>
<varlistentry>
- <term><literal>ADD [ BEFORE | AFTER ]</literal></term>
+ <term><literal>ADD LABEL [ BEFORE | AFTER ]</literal></term>
<listitem>
<para>
This form adds a new value to an enum type. If the new value's place in
@@ -238,7 +238,7 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD <replaceable cl
<title>Notes</title>
<para>
- <command>ALTER TYPE ... ADD</> (the form that adds a new value to an
+ <command>ALTER TYPE ... ADD LABEL</> (the form that adds a new value to an
enum type) cannot be executed inside a transaction block.
</para>
@@ -292,7 +292,7 @@ ALTER TYPE compfoo ADD ATTRIBUTE f3 int;
<para>
To add a new value to an enum type in a particular sort position:
<programlisting>
-ALTER TYPE colors ADD 'orange' AFTER 'red';
+ALTER TYPE colors ADD LABEL 'orange' AFTER 'red';
</programlisting>
</para>
</refsect1>
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 1394b21..5847531 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -3871,30 +3871,30 @@ enum_val_list: Sconst
*****************************************************************************/
AlterEnumStmt:
- ALTER TYPE_P any_name ADD_P Sconst
+ ALTER TYPE_P any_name ADD_P LABEL Sconst
{
AlterEnumStmt *n = makeNode(AlterEnumStmt);
n->typeName = $3;
- n->newVal = $5;
+ n->newVal = $6;
n->newValNeighbor = NULL;
n->newValIsAfter = true;
$$ = (Node *) n;
}
- | ALTER TYPE_P any_name ADD_P Sconst BEFORE Sconst
+ | ALTER TYPE_P any_name ADD_P LABEL Sconst BEFORE Sconst
{
AlterEnumStmt *n = makeNode(AlterEnumStmt);
n->typeName = $3;
- n->newVal = $5;
- n->newValNeighbor = $7;
+ n->newVal = $6;
+ n->newValNeighbor = $8;
n->newValIsAfter = false;
$$ = (Node *) n;
}
- | ALTER TYPE_P any_name ADD_P Sconst AFTER Sconst
+ | ALTER TYPE_P any_name ADD_P LABEL Sconst AFTER Sconst
{
AlterEnumStmt *n = makeNode(AlterEnumStmt);
n->typeName = $3;
- n->newVal = $5;
- n->newValNeighbor = $7;
+ n->newVal = $6;
+ n->newValNeighbor = $8;
n->newValIsAfter = true;
$$ = (Node *) n;
}
diff --git a/src/test/regress/expected/enum.out b/src/test/regress/expected/enum.out
index b1ba3f1..34ecc86 100644
--- a/src/test/regress/expected/enum.out
+++ b/src/test/regress/expected/enum.out
@@ -39,7 +39,7 @@ ORDER BY 2;
mars | 3
(3 rows)
-ALTER TYPE planets ADD 'uranus';
+ALTER TYPE planets ADD LABEL 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
WHERE enumtypid = 'planets'::regtype
@@ -52,10 +52,10 @@ ORDER BY 2;
uranus | 4
(4 rows)
-ALTER TYPE planets ADD 'mercury' BEFORE 'venus';
-ALTER TYPE planets ADD 'saturn' BEFORE 'uranus';
-ALTER TYPE planets ADD 'jupiter' AFTER 'mars';
-ALTER TYPE planets ADD 'neptune' AFTER 'uranus';
+ALTER TYPE planets ADD LABEL 'mercury' BEFORE 'venus';
+ALTER TYPE planets ADD LABEL 'saturn' BEFORE 'uranus';
+ALTER TYPE planets ADD LABEL 'jupiter' AFTER 'mars';
+ALTER TYPE planets ADD LABEL 'neptune' AFTER 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
WHERE enumtypid = 'planets'::regtype
@@ -89,46 +89,46 @@ ORDER BY enumlabel::planets;
(8 rows)
-- errors for adding labels
-ALTER TYPE planets ADD
+ALTER TYPE planets ADD LABEL
'plutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutopluto';
ERROR: invalid enum label "plutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutopluto"
DETAIL: Labels must be 63 characters or less.
-ALTER TYPE planets ADD 'pluto' AFTER 'zeus';
+ALTER TYPE planets ADD LABEL 'pluto' AFTER 'zeus';
ERROR: "zeus" is not an existing enum label
--
-- Test inserting so many values that we have to renumber
--
create type insenum as enum ('L1', 'L2');
-alter type insenum add 'i1' before 'L2';
-alter type insenum add 'i2' before 'L2';
-alter type insenum add 'i3' before 'L2';
-alter type insenum add 'i4' before 'L2';
-alter type insenum add 'i5' before 'L2';
-alter type insenum add 'i6' before 'L2';
-alter type insenum add 'i7' before 'L2';
-alter type insenum add 'i8' before 'L2';
-alter type insenum add 'i9' before 'L2';
-alter type insenum add 'i10' before 'L2';
-alter type insenum add 'i11' before 'L2';
-alter type insenum add 'i12' before 'L2';
-alter type insenum add 'i13' before 'L2';
-alter type insenum add 'i14' before 'L2';
-alter type insenum add 'i15' before 'L2';
-alter type insenum add 'i16' before 'L2';
-alter type insenum add 'i17' before 'L2';
-alter type insenum add 'i18' before 'L2';
-alter type insenum add 'i19' before 'L2';
-alter type insenum add 'i20' before 'L2';
-alter type insenum add 'i21' before 'L2';
-alter type insenum add 'i22' before 'L2';
-alter type insenum add 'i23' before 'L2';
-alter type insenum add 'i24' before 'L2';
-alter type insenum add 'i25' before 'L2';
-alter type insenum add 'i26' before 'L2';
-alter type insenum add 'i27' before 'L2';
-alter type insenum add 'i28' before 'L2';
-alter type insenum add 'i29' before 'L2';
-alter type insenum add 'i30' before 'L2';
+alter type insenum add label 'i1' before 'L2';
+alter type insenum add label 'i2' before 'L2';
+alter type insenum add label 'i3' before 'L2';
+alter type insenum add label 'i4' before 'L2';
+alter type insenum add label 'i5' before 'L2';
+alter type insenum add label 'i6' before 'L2';
+alter type insenum add label 'i7' before 'L2';
+alter type insenum add label 'i8' before 'L2';
+alter type insenum add label 'i9' before 'L2';
+alter type insenum add label 'i10' before 'L2';
+alter type insenum add label 'i11' before 'L2';
+alter type insenum add label 'i12' before 'L2';
+alter type insenum add label 'i13' before 'L2';
+alter type insenum add label 'i14' before 'L2';
+alter type insenum add label 'i15' before 'L2';
+alter type insenum add label 'i16' before 'L2';
+alter type insenum add label 'i17' before 'L2';
+alter type insenum add label 'i18' before 'L2';
+alter type insenum add label 'i19' before 'L2';
+alter type insenum add label 'i20' before 'L2';
+alter type insenum add label 'i21' before 'L2';
+alter type insenum add label 'i22' before 'L2';
+alter type insenum add label 'i23' before 'L2';
+alter type insenum add label 'i24' before 'L2';
+alter type insenum add label 'i25' before 'L2';
+alter type insenum add label 'i26' before 'L2';
+alter type insenum add label 'i27' before 'L2';
+alter type insenum add label 'i28' before 'L2';
+alter type insenum add label 'i29' before 'L2';
+alter type insenum add label 'i30' before 'L2';
-- The exact values of enumsortorder will now depend on the local properties
-- of float4, but in any reasonable implementation we should get at least
-- 20 splits before having to renumber; so only hide values > 20.
diff --git a/src/test/regress/sql/enum.sql b/src/test/regress/sql/enum.sql
index 70bf8c5..fa7e755 100644
--- a/src/test/regress/sql/enum.sql
+++ b/src/test/regress/sql/enum.sql
@@ -26,17 +26,17 @@ FROM pg_enum
WHERE enumtypid = 'planets'::regtype
ORDER BY 2;
-ALTER TYPE planets ADD 'uranus';
+ALTER TYPE planets ADD LABEL 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
WHERE enumtypid = 'planets'::regtype
ORDER BY 2;
-ALTER TYPE planets ADD 'mercury' BEFORE 'venus';
-ALTER TYPE planets ADD 'saturn' BEFORE 'uranus';
-ALTER TYPE planets ADD 'jupiter' AFTER 'mars';
-ALTER TYPE planets ADD 'neptune' AFTER 'uranus';
+ALTER TYPE planets ADD LABEL 'mercury' BEFORE 'venus';
+ALTER TYPE planets ADD LABEL 'saturn' BEFORE 'uranus';
+ALTER TYPE planets ADD LABEL 'jupiter' AFTER 'mars';
+ALTER TYPE planets ADD LABEL 'neptune' AFTER 'uranus';
SELECT enumlabel, enumsortorder
FROM pg_enum
@@ -49,10 +49,10 @@ WHERE enumtypid = 'planets'::regtype
ORDER BY enumlabel::planets;
-- errors for adding labels
-ALTER TYPE planets ADD
+ALTER TYPE planets ADD LABEL
'plutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutoplutopluto';
-ALTER TYPE planets ADD 'pluto' AFTER 'zeus';
+ALTER TYPE planets ADD LABEL 'pluto' AFTER 'zeus';
--
-- Test inserting so many values that we have to renumber
@@ -60,36 +60,36 @@ ALTER TYPE planets ADD 'pluto' AFTER 'zeus';
create type insenum as enum ('L1', 'L2');
-alter type insenum add 'i1' before 'L2';
-alter type insenum add 'i2' before 'L2';
-alter type insenum add 'i3' before 'L2';
-alter type insenum add 'i4' before 'L2';
-alter type insenum add 'i5' before 'L2';
-alter type insenum add 'i6' before 'L2';
-alter type insenum add 'i7' before 'L2';
-alter type insenum add 'i8' before 'L2';
-alter type insenum add 'i9' before 'L2';
-alter type insenum add 'i10' before 'L2';
-alter type insenum add 'i11' before 'L2';
-alter type insenum add 'i12' before 'L2';
-alter type insenum add 'i13' before 'L2';
-alter type insenum add 'i14' before 'L2';
-alter type insenum add 'i15' before 'L2';
-alter type insenum add 'i16' before 'L2';
-alter type insenum add 'i17' before 'L2';
-alter type insenum add 'i18' before 'L2';
-alter type insenum add 'i19' before 'L2';
-alter type insenum add 'i20' before 'L2';
-alter type insenum add 'i21' before 'L2';
-alter type insenum add 'i22' before 'L2';
-alter type insenum add 'i23' before 'L2';
-alter type insenum add 'i24' before 'L2';
-alter type insenum add 'i25' before 'L2';
-alter type insenum add 'i26' before 'L2';
-alter type insenum add 'i27' before 'L2';
-alter type insenum add 'i28' before 'L2';
-alter type insenum add 'i29' before 'L2';
-alter type insenum add 'i30' before 'L2';
+alter type insenum add label 'i1' before 'L2';
+alter type insenum add label 'i2' before 'L2';
+alter type insenum add label 'i3' before 'L2';
+alter type insenum add label 'i4' before 'L2';
+alter type insenum add label 'i5' before 'L2';
+alter type insenum add label 'i6' before 'L2';
+alter type insenum add label 'i7' before 'L2';
+alter type insenum add label 'i8' before 'L2';
+alter type insenum add label 'i9' before 'L2';
+alter type insenum add label 'i10' before 'L2';
+alter type insenum add label 'i11' before 'L2';
+alter type insenum add label 'i12' before 'L2';
+alter type insenum add label 'i13' before 'L2';
+alter type insenum add label 'i14' before 'L2';
+alter type insenum add label 'i15' before 'L2';
+alter type insenum add label 'i16' before 'L2';
+alter type insenum add label 'i17' before 'L2';
+alter type insenum add label 'i18' before 'L2';
+alter type insenum add label 'i19' before 'L2';
+alter type insenum add label 'i20' before 'L2';
+alter type insenum add label 'i21' before 'L2';
+alter type insenum add label 'i22' before 'L2';
+alter type insenum add label 'i23' before 'L2';
+alter type insenum add label 'i24' before 'L2';
+alter type insenum add label 'i25' before 'L2';
+alter type insenum add label 'i26' before 'L2';
+alter type insenum add label 'i27' before 'L2';
+alter type insenum add label 'i28' before 'L2';
+alter type insenum add label 'i29' before 'L2';
+alter type insenum add label 'i30' before 'L2';
-- The exact values of enumsortorder will now depend on the local properties
-- of float4, but in any reasonable implementation we should get at least
--
1.7.1
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Dean Rasheed's message of mar oct 26 15:46:56 -0300 2010:
Well ELEMENT is a reserved keyword in SQL:2008, to support multisets,
so if we ever supported that feature...
Hah!
Hmmm ... I dug through SQL:2008, and so far as I can find, the only use
of ELEMENT as a keyword is for <multiset element reference>, which
is defined as "return the sole element of a multiset of one element":
<multiset element reference> ::= ELEMENT <left paren> <multiset value expression> <right paren>
This is stated to be equivalent to
( SELECT M.E FROM UNNEST (mve) AS M(E) )
AFAICS, if we were to implement this, we'd do it as an ordinary function
named element(), just like unnest() is an ordinary function in our
implementation. Reserving a common word for as tiny of a notational
savings as this would be stupid.
Of course, it's possible that in future versions the committee might
extend ELEMENT() in ways that we can't duplicate as a simple function.
But that's all hypothetical --- you could as well argue that they might
decide to reserve any other word, too.
But ... having said all that, I have to agree that ELEMENT seems
preferable to LABEL if we ignore micro-considerations of parser
efficiency --- I still think LABEL is a pretty poor choice of word
here. Personally I'd still take VALUE as being my first choice though.
regards, tom lane
On 27 October 2010 02:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Dean Rasheed's message of mar oct 26 15:46:56 -0300 2010:
Well ELEMENT is a reserved keyword in SQL:2008, to support multisets,
so if we ever supported that feature...Hah!
Hmmm ... I dug through SQL:2008, and so far as I can find, the only use
of ELEMENT as a keyword is for <multiset element reference>, which
is defined as "return the sole element of a multiset of one element":<multiset element reference> ::= ELEMENT <left paren> <multiset value expression> <right paren>
This is stated to be equivalent to
( SELECT M.E FROM UNNEST (mve) AS M(E) )
AFAICS, if we were to implement this, we'd do it as an ordinary function
named element(), just like unnest() is an ordinary function in our
implementation. Reserving a common word for as tiny of a notational
savings as this would be stupid.Of course, it's possible that in future versions the committee might
extend ELEMENT() in ways that we can't duplicate as a simple function.
But that's all hypothetical --- you could as well argue that they might
decide to reserve any other word, too.
Yeah, so far there appears to be only one place where ELEMENT is used
in syntax, and that could be a function, rather than requiring a
keyword. OTOH, the word "element" is used extensively throughout
SQL:2008 to refer to the elements of various types of collection
(arrays, sets and multisets). Likewise in the wider literature.
If the SQL standard does get around to describing enumerations, it is
not unreasonable to assume that it would use "element" there too, in
all documentation, if not in actual syntax.
Then it seems only logical to have the syntax match the terminology
used in the documentation.
So the more I think about this, the more convinced I am that ELEMENT
is the right word.
Regards,
Dean
Show quoted text
But ... having said all that, I have to agree that ELEMENT seems
preferable to LABEL if we ignore micro-considerations of parser
efficiency --- I still think LABEL is a pretty poor choice of word
here. Personally I'd still take VALUE as being my first choice though.regards, tom lane
Alvaro Herrera <alvherre@commandprompt.com> wrote:
Excerpts from Dean Rasheed's message:
Well ELEMENT is a reserved keyword in SQL:2008, to support
multisets, so if we ever supported that feature...Hah!
Well, here's a patch for LABEL in any case. If we're going to
have to reserve ELEMENT in the future then there doesn't seem to
be much point in not choosing that one though.
FWIW, I like ELEMENT better than LABEL. The reason I don't like
VALUE is that you are specifying the logical *name* of the entry,
and it seems clumsy not to have a convenient word for the value that
the name maps to, internally. You're actually adding the name and
assigning it a value, which corresponds well to ELEMENT.
-Kevin
On 10/26/2010 09:16 PM, Tom Lane wrote:
But ... having said all that, I have to agree that ELEMENT seems
preferable to LABEL if we ignore micro-considerations of parser
efficiency --- I still think LABEL is a pretty poor choice of word
here. Personally I'd still take VALUE as being my first choice though.
Speculation about what the SQL standards might contain at some stage if
they ever supported enums seems to be drawing a bit of a long bow, so
I'm not terribly convinced by that line of reasoning.
The reason I chose LABEL was that it's consistent with what we have used
elsewhere, both in the docs and the catalog. But I'm not strongly wedded
to it. If it's a choice between ELEMENT and VALUE, I too prefer VALUE at
it seems likelier to convey the sense of what we're doing to a naive user.
cheers
andrew
On 10/27/2010 10:00 AM, Kevin Grittner wrote:
Alvaro Herrera<alvherre@commandprompt.com> wrote:
Excerpts from Dean Rasheed's message:
Well ELEMENT is a reserved keyword in SQL:2008, to support
multisets, so if we ever supported that feature...Hah!
Well, here's a patch for LABEL in any case. If we're going to
have to reserve ELEMENT in the future then there doesn't seem to
be much point in not choosing that one though.FWIW, I like ELEMENT better than LABEL. The reason I don't like
VALUE is that you are specifying the logical *name* of the entry,
and it seems clumsy not to have a convenient word for the value that
the name maps to, internally. You're actually adding the name and
assigning it a value, which corresponds well to ELEMENT.
*sigh*
No, we are not. At the SQL level the name *is* the value. The fact that
we store an enum as an Oid has no relevance to the abstract type.
Calling the Oid the value makes as much sense as saying that the
compressed bytes we store in a toasted text field are the value of the
field. We don't have any way to refer to that either. Using Oids is an
implementation detail that makes no difference to the type's semantics.
Why would we want to refer to the type's internal representation at all
in SQL? There is exactly one slightly visible place where it's at all
interesting, and that's binary upgrade. And we carefully don't use an
SQL mechanism to handle that case. Other than that it should be of no
interest to anyone other than a hacker.
cheers
andrew
Excerpts from Andrew Dunstan's message of mié oct 27 11:18:44 -0300 2010:
The reason I chose LABEL was that it's consistent with what we have used
elsewhere, both in the docs and the catalog. But I'm not strongly wedded
to it. If it's a choice between ELEMENT and VALUE, I too prefer VALUE at
it seems likelier to convey the sense of what we're doing to a naive user.
Wow, this must be the most difficult smallest thing I have ever seen
discussed in pg-hackers. It doesn't seem like there are enough votes
in any particular direction. Now *this* is proper bikeshedding.
Should we ask more openly in another thread, with a different, more
catchy subject?
And I just realized that my patch lacks psql tab completion support.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Oct 27, 2010, at 7:18 AM, Andrew Dunstan wrote:
The reason I chose LABEL was that it's consistent with what we have used elsewhere, both in the docs and the catalog. But I'm not strongly wedded to it. If it's a choice between ELEMENT and VALUE, I too prefer VALUE at it seems likelier to convey the sense of what we're doing to a naive user.
FWIW, MySQL seems to call them values:
An ENUM is a string object with a value chosen from a list of permitted values that are enumerated explicitly in the column specification at table creation time.
-- http://dev.mysql.com/doc/refman/5.0/en/enum.html
Best,
David
On 26 October 2010 02:48, Andrew Dunstan <andrew@dunslane.net> wrote:
It occurred to me in the dead of the night that instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
It's a real shame we can't have
ALTER ENUM works ADD spanner;
That way it wouldn't matter whether you think of 'spanner' as a
label/value/item/element/thingy.
Cheers,
BJ
On Wed, Oct 27, 2010 at 08:57, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
articular direction. Now *this* is proper bikeshedding.
Should we ask more openly in another thread, with a different, more
catchy subject?
Wait you want more bikeshedding? :P Anyway If I look at the original concern:
...instead of:
ALTER TYPE enumtype ADD 'newlabel'
it might be better to have:
ALTER TYPE enumtype ADD LABEL 'newlabel'
That way if we later wanted to support some other sort of ADD operation on types we would be able to more easily.
I have not seen anyone suggest what those other add operations might
be. Maybe the thing to-do is leave it alone. That is naked ADD,
neither VALUE or LABEL.
However, in the interest of progress-- +1 for VALUE; Its how I
naturally tried to "do it" in psql.
Hello, Andrew.
You wrote:
AD> It occurred to me in the dead of the night that instead of:
AD> ALTER TYPE enumtype ADD 'newlabel'
AD> it might be better to have:
AD> ALTER TYPE enumtype ADD LABEL 'newlabel'
AD> That way if we later wanted to support some other sort of ADD operation
AD> on types we would be able to more easily. LABEL is already a keyword, so
AD> it should be pretty minimally invasive to make this change, and if we
AD> want to do it now is the time.
AD> Thoughts?
AD> cheers
AD> andrew
I'm with you.
BTW, I wrote post with poll about this.
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
Hello, Andrew.
You wrote:
AD> It occurred to me in the dead of the night that instead of:
AD> ALTER TYPE enumtype ADD 'newlabel'
AD> it might be better to have:
AD> ALTER TYPE enumtype ADD LABEL 'newlabel'
AD> That way if we later wanted to support some other sort of ADD operation
AD> on types we would be able to more easily. LABEL is already a keyword, so
AD> it should be pretty minimally invasive to make this change, and if we
AD> want to do it now is the time.
AD> Thoughts?
AD> cheers
AD> andrew
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
Hah, there are 17 votes as of right now, no option is below 23% and no
option is above 29%.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hello, Alvaro.
You wrote:
AH> Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
AH> Hah, there are 17 votes as of right now, no option is below 23% and no
AH> option is above 29%.
Yeah, right now 42 votes:
VALUE 26%
LABEL 26%
Just ADD 'newlabel' 24%
ELEMENT 21%
MEMBER 2%
--
With best wishes,
Pavel mailto:pavel@gf.microolap.com
On 10/29/2010 01:47 AM, Pavel Golub wrote:
Hello, Alvaro.
You wrote:
AH> Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/AH> Hah, there are 17 votes as of right now, no option is below 23% and no
AH> option is above 29%.Yeah, right now 42 votes:
VALUE 26%
LABEL 26%
Just ADD 'newlabel' 24%
ELEMENT 21%
MEMBER 2%
It's fairly unscientific and inconclusive, and the discussion seems to
have died. I think since Tom and I did most of the work on this our
voices should count a little louder :-) , so I'm going to go with his
suggestion of VALUE, unless there are loud squawks.
cheers
andrew
On Nov 14, 2010, at 7:42 AM, Andrew Dunstan wrote:
It's fairly unscientific and inconclusive, and the discussion seems to have died. I think since Tom and I did most of the work on this our voices should count a little louder :-) , so I'm going to go with his suggestion of VALUE, unless there are loud squawks.
+1
Maybe update the doc mentions of "label," then.
David