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
