Re: Call for objections: revision of keyword classification

Tom Lane writes:

> The keyword classification now looks like:
>
> TypeFuncId:    IDENT plus all fully-unrestricted keywords
>
> ColId:        TypeFuncId plus type-name keywords that might be
>         followed by '('; these can't be allowed to be
>         function names, but they can be column names.
>
> func_name:    TypeFuncId plus a few special-case ColLabels
>         (this list could probably be extended further)
>
> ColLabel:    ColId plus everything else
>
> Comments?  I'd like to apply this, unless there are objections.

Is there any reason why ColLabel does not include func_name?  All the
tokens listed in func_name are also part of ColLabel.

> I suppose Peter might complain about having to redo the keyword
> tables ;-)

The question is, do we want to give the user that much detail, or should
we just say

TypeFuncId, ColId -> "non-reserved"
func_name, ColLabel -> "reserved" (along with the explanations in the
text)

The plain reserved/non-reserved scheme makes it easier to match up the
PostgreSQL column with the SQL9x columns, and hopefully less users will
nitpick about whatever details or consider the categories a promise for
all future.

-- 
Peter Eisentraut   peter_e@gmx.net