s/LABEL/VALUE/ for ENUMs
Patch attached.
Best,
David
Attachments:
enum_value.patchapplication/octet-stream; name=enum_value.patch; x-unix-mode=0644Download
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 02eaedf..a88a01c 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -2975,19 +2975,19 @@ SELECT person.name, holidays.num_weeks FROM person, holidays
<para>
An enum value occupies four bytes on disk. The length of an enum
- value's textual label is limited by the <symbol>NAMEDATALEN</symbol>
+ value is limited by the <symbol>NAMEDATALEN</symbol>
setting compiled into <productname>PostgreSQL</productname>; in standard
builds this means at most 63 bytes.
</para>
<para>
- Enum labels are case sensitive, so
+ Enum values are case sensitive, so
<type>'happy'</type> is not the same as <type>'HAPPY'</type>.
- White space in the labels is significant too.
+ White space in the value is significant too.
</para>
<para>
- The translations from internal enum values to textual labels are
+ The translations from internal enum values to textual values are
kept in the system catalog
<link linkend="catalog-pg-enum"><structname>pg_enum</structname></link>.
Querying this catalog directly can be useful.
diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml
index a3c75b5..c48b756 100644
--- a/doc/src/sgml/ref/create_type.sgml
+++ b/doc/src/sgml/ref/create_type.sgml
@@ -25,7 +25,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable> AS
( [ <replaceable class="PARAMETER">attribute_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [, ... ] ] )
CREATE TYPE <replaceable class="parameter">name</replaceable> AS ENUM
- ( [ '<replaceable class="parameter">label</replaceable>' [, ... ] ] )
+ ( [ '<replaceable class="parameter">value</replaceable>' [, ... ] ] )
CREATE TYPE <replaceable class="parameter">name</replaceable> (
INPUT = <replaceable class="parameter">input_function</replaceable>,
@@ -90,7 +90,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
<para>
The second form of <command>CREATE TYPE</command> creates an enumerated
(enum) type, as described in <xref linkend="datatype-enum">.
- Enum types take a list of one or more quoted labels, each of which
+ Enum types take a list of one or more quoted values, each of which
must be less than <symbol>NAMEDATALEN</symbol> bytes long (64 in a standard
<productname>PostgreSQL</productname> build).
</para>
@@ -426,10 +426,10 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
</varlistentry>
<varlistentry>
- <term><replaceable class="parameter">label</replaceable></term>
+ <term><replaceable class="parameter">value</replaceable></term>
<listitem>
<para>
- A string literal representing the textual label associated with
+ A string literal representing the textual value associated with
one value of an enum type.
</para>
</listitem>
On 11/22/2010 06:36 PM, David E. Wheeler wrote:
Patch attached.
Thanks, I'll look at this shortly. I think it needs a little bit more,
which I'll do. In particular, we should now avoid using the word 'value'
to refer to the internal representation of an enum - that will just be
confusing.
cheers
andrew
"David E. Wheeler" <david@kineticode.com> writes:
Patch attached.
Most of those changes seem like they make it less readable, not more so.
In particular I don't find it an improvement to replace "textual label"
with "textual value". I think of "value" as meaning some abstract
notion of a particular enum member, which is not identical to the
concrete text string that represents it. If you consider them the same
thing then renaming an enum value would be a meaningless concept.
Maybe instead of "textual label", we should say "name"? But that
doesn't seem like quite le mot juste either. "label" is actually a
pretty good word for the text representation of an enum value.
regards, tom lane
On 11/22/2010 06:57 PM, Tom Lane wrote:
"David E. Wheeler"<david@kineticode.com> writes:
Patch attached.
Most of those changes seem like they make it less readable, not more so.
In particular I don't find it an improvement to replace "textual label"
with "textual value". I think of "value" as meaning some abstract
notion of a particular enum member, which is not identical to the
concrete text string that represents it. If you consider them the same
thing then renaming an enum value would be a meaningless concept.Maybe instead of "textual label", we should say "name"? But that
doesn't seem like quite le mot juste either. "label" is actually a
pretty good word for the text representation of an enum value.
Oh my boots and buttons. I think we're splitting some very fine hairs
here. A few weeks back you were telling us that label wasn't a very good
word and shouldn't be sanctified in the SQL.
I don't mind that much leaving it as it is, but we do seem to be
straining at gnats a bit.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 11/22/2010 06:57 PM, Tom Lane wrote:
Maybe instead of "textual label", we should say "name"? But that
doesn't seem like quite le mot juste either. "label" is actually a
pretty good word for the text representation of an enum value.
Oh my boots and buttons. I think we're splitting some very fine hairs
here. A few weeks back you were telling us that label wasn't a very good
word and shouldn't be sanctified in the SQL.
It isn't a very good word for the abstract value, IMO, but the text
representation is a different concept.
regards, tom lane
On Nov 22, 2010, at 4:46 PM, Tom Lane wrote:
Oh my boots and buttons. I think we're splitting some very fine hairs
here. A few weeks back you were telling us that label wasn't a very good
word and shouldn't be sanctified in the SQL.It isn't a very good word for the abstract value, IMO, but the text
representation is a different concept.
But that's the thing we've been talking about all along! It's now
ALTER ENUM ADD VALUE 'FOO';
But that sets the text value, the label, not the abstract value.
Boots and buttons indeed.
David
On Mon, Nov 22, 2010 at 7:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 11/22/2010 06:57 PM, Tom Lane wrote:
Maybe instead of "textual label", we should say "name"? But that
doesn't seem like quite le mot juste either. "label" is actually a
pretty good word for the text representation of an enum value.Oh my boots and buttons. I think we're splitting some very fine hairs
here. A few weeks back you were telling us that label wasn't a very good
word and shouldn't be sanctified in the SQL.It isn't a very good word for the abstract value, IMO, but the text
representation is a different concept.
+1 for what Andrew said.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
Or we could call it "extraint conclusions". ;-)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On 11/22/10 5:38 PM, Josh Berkus wrote:
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
... "original patch". Sorry. Let's not fiddle with the names.
Or we could call it "extraint conclusions". ;-)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
... "original patch". Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new command is:
ALTER TYPE name ADD VALUE new_enum_value [ { BEFORE | AFTER } existing_enum_value ]
So while the term in the SQL statement is "VALUE," it's called a "label" in the documentation. I think that's confusing. Does anyone else?
Best
David
On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler <david@kineticode.com> wrote:
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
... "original patch". Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new command is:
ALTER TYPE name ADD VALUE new_enum_value [ { BEFORE | AFTER } existing_enum_value ]
So while the term in the SQL statement is "VALUE," it's called a "label" in the documentation. I think that's confusing. Does anyone else?
Yes. As between the two options, I favor changing the command. And
let's also paint it pink.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Nov 23, 2010, at 11:48 AM, Robert Haas wrote:
So while the term in the SQL statement is "VALUE," it's called a "label" in the documentation. I think that's confusing. Does anyone else?
Yes. As between the two options, I favor changing the command. And
let's also paint it pink.
Would that go with Andrew's boots and buttons?
Best,
David
On Tue, 2010-11-23 at 14:48 -0500, Robert Haas wrote:
On Tue, Nov 23, 2010 at 2:01 PM, David E. Wheeler <david@kineticode.com> wrote:
On Nov 22, 2010, at 6:03 PM, Josh Berkus wrote:
... "original patch". Sorry. Let's not fiddle with the names.
To be clear, as things stand now, the new command is:
ALTER TYPE name ADD VALUE new_enum_value [ { BEFORE | AFTER } existing_enum_value ]
So while the term in the SQL statement is "VALUE," it's called a "label" in the documentation. I think that's confusing. Does anyone else?
Yes. As between the two options, I favor changing the command. And
let's also paint it pink.
We discussed this at West remember? When asked to paint a wall black we
ask, "which shade?".
JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Josh Berkus wrote:
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.Or we could call it "extraint conclusions". ;-)
I vote for "extraint confusions".
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +