Re: PostgreSQL vs SQL Standard - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL vs SQL Standard
Date
Msg-id 4161.1528644776@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL vs SQL Standard  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: PostgreSQL vs SQL Standard
Re: PostgreSQL vs SQL Standard
Re: PostgreSQL vs SQL Standard
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL vs SQL Standard
Next
From: Dmitry Dolgov
Date:
Subject: Re: assert in nested SQL procedure call in current HEAD