On Tue, May 19, 2020 at 7:47 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > As Robert theorized, it works to move a fairly-small number of unreserved > keywords into a new slightly-reserved category.
It wasn't entirely a theoretical argument, since I'm pretty sure I did spend some time experimenting with gram.y back in the day, but possibly not to the extent that you've done here. And I seem not to have saved my work, either... > However, as the patch > stands, only the remaining fully-unreserved keywords can be used as bare > column labels. I'd hoped to be able to also use col_name keywords in that > way (which'd make the set of legal bare column labels mostly the same as > ColId). The col_name keywords that cause problems are, it appears, > only PRECISION, CHARACTER, and CHAR_P. So in principle we could move > those three into yet another keyword category and then let the remaining > col_name keywords be included in BareColLabel. I kind of think that > that's more complication than it's worth, though. I think it's a judgement call. If all we do is what you have in the patch, we can make 288 keywords that currently aren't usable as column labels without AS, plus future unreserved keywords that get similar treatment. If we also split the column-name keywords, then we can buy ourselves another 48 keywords that can be used as column labels without AS. Presumably everybody is going to agree that allowing more keywords to be used this way is better than fewer, but also that having fewer keyword classifications is better than having more, and those goals are in tension in this case. I believe that most, possibly all, of the examples of this problem that I have seen involve unreserved keywords, but that might just because there are a lot more unreserved keywords than there are keywords of any other sort. Things like TIME, POSITION, and VALUES don't seem like particularly unlikely choices for a column label. I mean, someone who knows SQL well and is a good programmer might not choose these things, either because they're kind of generic, or because they're known to have special meaning in SQL. However, SQL is used by many people who don't know it well and aren't good programmers, and people coming from other database systems generally don't have to worry much about their choice of column labels and then get sad when their migration fails. So I'd be somewhat inclined to see how far we can reasonably push this, but I'm also entirely willing to accept that 85% of a loaf is better than none. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company