> On Jun 30, 2020, at 2:47 PM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>
>
>> On May 19, 2020, at 4:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> I wrote:
>>> However, we do have to have a benefit to show those people whose
>>> queries we break. Hence my insistence on having a working AS fix
>>> (or some other benefit) before not after.
>>
>> I experimented with this a bit more, and came up with the attached.
>> It's not a working patch, just a set of grammar changes that Bison
>> is happy with. (Getting to a working patch would require fixing the
>> various build infrastructure that knows about the keyword classification,
>> which seems straightforward but tedious.)
>
> I built a patch on top of yours that does much of that tedious work.
>
>> As Robert theorized, it works to move a fairly-small number of unreserved
>> keywords into a new slightly-reserved category. 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.
>
> By my count, 288 more keywords can be used as column aliases without the AS keyword after the patch. That exactly
matcheswhat Robert said upthread.
>
> Tom and Álvaro discussed upthread:
>
>> Would it make sense (and possible) to have a keyword category that is
>> not disjoint wrt. the others? Maybe that ends up being easier than
>> a solution that ends up with six or seven categories.
Version 2, attached, follows this design, increasing the number of keywords that can be used as column aliases without
theAS keyword up to 411, with only 39 keywords still requiring an explicit preceding AS.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company