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