Re: Call for objections: revision of keyword classification

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Is there any reason why ColLabel does not include func_name? All the
> tokens listed in func_name are also part of ColLabel.

Can't do it directly (ie, make func_name one of the alternatives for
ColLabel) because that would result in a ton of shift-reduce conflicts:
all the keywords in TypeFuncId would have two ways to be reduced to
ColLabel (via ColId or via func_name). We could restructure things
by adding an auxiliary category:

func_name: TypeFuncId | func_name_keywords;

func_name_keywords: BETWEEN | BINARY | ... ;

ColLabel: ColId | func_name_keywords | ALL | ANALYSE | ... ;

but I'm not convinced that that's materially cleaner. Comments?

> 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)

ColId is certainly the most important category for ordinary users, so
I agree that division would be sufficient for most people's purposes.
However ... seems like the point of having this documentation at all
is for it to be complete and accurate. I'd vote for telling the whole
truth, I think.

regards, tom lane