Re: 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(at)dunslane(dot)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
>
>
> 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(at)postgresql(dot)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(dot)stehule(at)gmail(dot)com> wrote:
> 2010/10/25 Andrew Dunstan <andrew(at)dunslane(dot)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(at)dunslane(dot)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(at)kineticode(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "David E. Wheeler"<david(at)kineticode(dot)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(at)dunslane(dot)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(at)dunslane(dot)net>:
>
>
> On 10/25/2010 02:51 PM, Robert Haas wrote:
>>
>> On Mon, Oct 25, 2010 at 2:41 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>>>
>>> "David E. Wheeler"<david(at)kineticode(dot)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

>
> cheers
>
> andrew
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)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(at)dunslane(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)kineticode(dot)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(at)kineticode(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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

>
> 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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)dunslane(dot)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(at)commandprompt(dot)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(at)gf(dot)microolap(dot)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(at)gf(dot)microolap(dot)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(at)commandprompt(dot)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(at)gf(dot)microolap(dot)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