From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL vs SQL Standard |
Date: | 2018-06-10 15:32:56 |
Message-ID: | 4161.1528644776@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> I beat at the grammar a bit to see what it would take to fix it at least
> to the extent of allowing a_expr ColId in a select list after removing
> postfix ops. It looked like it was doable by making these keywords more
> reserved (all of which are already reserved words per spec):
> DOUBLE, DAY, FILTER, HOUR, MINUTE, MONTH, OVER, PRECISION, SECOND,
> VARYING, WITHIN, WITHOUT, YEAR
Yeah, a side effect of allowing "a_expr ColId" is that we can expect,
going forward, that a lot of new keywords are going to have to become
fully reserved that otherwise wouldn't have to be. This is particularly
a problem because of the SQL committee's COBOL-hangover tendency to
invent new syntax that involves sequences of keywords; we usually
don't have a good way to deal with that short of making the first
keyword(s) reserved.
It's arguable that going down that path will, in the long run, lead to
breaking more applications (via their table/column names suddenly becoming
reserved in some new version) than we rescue from having to quote their
SELECT aliases. At the very least we need to recognize that this is far
from cost-free.
(wanders away wondering exactly what parsing technology the SQL committee
thinks implementations use...)
regards, tom lane
PS: My older message about this mentioned only the VARYING and ISNULL
cases, which I think means that I had ideas about how not to have to
reserve the other ones you mention. But the larger point holds.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2018-06-10 19:06:59 | Re: assert in nested SQL procedure call in current HEAD |
Previous Message | Tom Lane | 2018-06-10 15:19:39 | Re: PostgreSQL vs SQL Standard |