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(at)gmx(dot)net