From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: factorial function/phase out postfix operators? |
Date: | 2020-05-20 21:54:18 |
Message-ID: | 20200520215418.GA28983@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-May-20, Tom Lane wrote:
> 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.)
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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-05-20 21:56:02 | Re: Change JOIN tutorial to focus more on explicit joins |
Previous Message | Thomas Munro | 2020-05-20 21:48:42 | Re: Parallel Seq Scan vs kernel read ahead |