Tom Lane wrote: > But some experimentation suggests that we could > fix that by subdividing col_name_keyword into two categories, one being > the keywords that can also be type names (BIGINT, BIT, etc) and one > being those that can't (BETWEEN, COALESCE, etc). Everywhere > col_name_keyword is used now, just mention both sub-categories. > And in def_arg, add a production for only the second sub-category. > > I think such a categorization would actually be cleaner than what we have > now; if you read the comments for col_name_keyword, they're pretty squishy > about whether these keywords can be type or function names or not, and > this subdivision would make that a little clearer. Interestingly, it > also seems that the grammar tables become slightly smaller, suggesting > that Bison also finds this more regular.
Sounds reasonable. We already have four categories, so one more shouldn't be a problem, and if Bison likes it then all the better. So you're talking about this: * Many of these keywords will in fact be recognized as type or function * names too; but they have special productions for the purpose, and so * can't be treated as "generic" type or function names. and you're saying that this comment will be moved to the first of these new categories and s/Many of these/These/. In other words, the "special productions" will remain, which this is the stuff under SimpleTypename, minus GenericType. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
