On 27 October 2010 02:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.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
>