Thread: s/LABEL/VALUE/ for ENUMs

s/LABEL/VALUE/ for ENUMs

From
"David E. Wheeler"
Date:
Patch attached.

Best,

David

Attachment

Re: s/LABEL/VALUE/ for ENUMs

From
Andrew Dunstan
Date:

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


Re: s/LABEL/VALUE/ for ENUMs

From
Tom Lane
Date:
"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


Re: s/LABEL/VALUE/ for ENUMs

From
Andrew Dunstan
Date:

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


Re: s/LABEL/VALUE/ for ENUMs

From
Tom Lane
Date:
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


Re: s/LABEL/VALUE/ for ENUMs

From
Robert Haas
Date:
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


Re: s/LABEL/VALUE/ for ENUMs

From
"David E. Wheeler"
Date:
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


Re: s/LABEL/VALUE/ for ENUMs

From
Josh Berkus
Date:
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
 


Re: s/LABEL/VALUE/ for ENUMs

From
Josh Berkus
Date:
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
 


Re: s/LABEL/VALUE/ for ENUMs

From
"David E. Wheeler"
Date:
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



Re: s/LABEL/VALUE/ for ENUMs

From
Robert Haas
Date:
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


Re: s/LABEL/VALUE/ for ENUMs

From
"David E. Wheeler"
Date:
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



Re: s/LABEL/VALUE/ for ENUMs

From
"Joshua D. Drake"
Date:
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



Re: s/LABEL/VALUE/ for ENUMs

From
Bruce Momjian
Date:
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. +