Thread: 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
Peter Eisentraut <peter_e@gmx.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
BTW, is there any good reason that AS is not a member of the ColLabel
set? It wouldn't cause a parse conflict to add it (I just tested that)
and it seems like that's a special case we could do without.
regards, tom lane
Tom Lane writes: > 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. Okay, here's the new definition of truth then: TypeFuncId => "non-reserved" ColId => "non-reserved (cannot be function or type)" func_name => "reserved (can be function)" ColId => "reserved" This can still be matched well against the SQL 9x columns. But it gets worse... ;-) I found that COALESCE, EXISTS, EXTRACT, NULLIF, POSITION, SUBSTRING, TRIM can be moved from ColLabel to ColId. (This makes sense given the new definition of ColId as above.) However, I *think* it should be possible to use these tokens as type names if one were willing to refactor these lists further. So there's possibly plenty of fun left in this area. ;-) -- Peter Eisentraut peter_e@gmx.net
Tom Lane writes: > BTW, is there any good reason that AS is not a member of the ColLabel > set? It wouldn't cause a parse conflict to add it (I just tested that) > and it seems like that's a special case we could do without. Fine with me. I guess I'll wait with the new table a bit yet. ;-) -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I found that COALESCE, EXISTS, EXTRACT, NULLIF, POSITION, SUBSTRING, TRIM
> can be moved from ColLabel to ColId.
Really? I didn't bother experimenting with anything that had special
a_expr productions ... but now that you mention it, it makes sense that
anything whose special meaning requires a following left paren could
work as a ColId.
Are you recommending that we actually make this change now, or leave
it for a future round of experiments?
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Fine with me. I guess I'll wait with the new table a bit yet. ;-)
The coast is clear now ...
I divided the keywords into four mutually exclusive, all inclusive
category lists:unreserved_keywordcol_name_keywordfunc_name_keywordreserved_keyword
which I trust will not be a problem for your document-generating
script.
ecpg has some finer distinctions but I'm happy to leave those
undocumented.
regards, tom lane