On 10/27/2010 10:00 AM, Kevin Grittner wrote:
> Alvaro Herrera<alvherre@commandprompt.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