Re: s/LABEL/VALUE/ for ENUMs

Patch attached.

Best,

David

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(at)kineticode(dot)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(at)kineticode(dot)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(at)dunslane(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)kineticode(dot)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(at)kineticode(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +