Re: factorial function/phase out postfix operators? - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 19, 2020 at 7:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

Right; I'd done the same arithmetic.  Since we currently have a total
of 450 keywords of all flavors, that means we can make either 64%
of them or 74.6% of them be safe to use as bare column labels.  While
that's surely better than today, it doesn't seem like it's going to
make for any sort of sea change in the extent of the problem.  So I was
feeling a bit discouraged by these results.

I too failed to save the results of some experimentation, but I'd
also poked at the type_func_name_keyword category, and it has a similar
situation where only about three keywords cause problems if included
in BareColLabel.  So we could possibly get another twenty-ish keywords
into that set with yet a third new keyword category.  But (a) we'd still
only be at 79% coverage and (b) this is *really* making things messy
keyword-category-wise.  I feel like we'd be better advised to somehow
treat can-be-bare-col-label as an independent classification.

(I did not look at whether any of the fully-reserved keywords could
be made safe to use, but it seems likely that at least some of them
could be, if we accept even more classification mess.)

Bottom line is that we can reduce the scope of the col-label problem
this way, but we can't make it go away entirely.  Is a partial solution
to that worth a full drop of postfix operators?  Possibly, but I'm not
sure.  I still feel like it'd be worth investigating some other solution
technology, ie lookahead, though I concede your point that that has
pitfalls too.

            regards, tom lane