On Tue, May 19, 2020 at 7:47 PM Tom Lane <tgl@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