Re: PostgreSQL vs SQL Standard

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.

In response to

Responses

Browse pgsql-hackers by date

  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