add label to enum syntax

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

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

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

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

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