> 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.
I didn't see much point in that. The way Tom had it in his patch was easy to work with. Maybe I'm missing something?
The patch, attached, still needs documentation updates and an update to pg_upgrade. Users upgrading to v14 may have
custompostfix operators. Should pg_upgrade leave them untouched? They wouldn't be reachable through the grammar any
longer. Should pg_upgrade delete them? I'm generally not in favor of deleting user data as part of an upgrade, and
rowsin the catalog tables corresponding to custom postfix operators are sort of user data, if you squint and look at
themjust right. Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
