Pavel Stehule <pavel.stehule@gmail.com> writes:
> Is there some description of what keywords should be reserved? If I
> remember correctly, the scanner was changed more times, and maybe more
> reserved keywords are not necessary.
Per the comment in pl_scanner.c:
* We try to avoid reserving more keywords than we have to; but there's
* little point in not reserving a word if it's reserved in the core grammar.
* Currently, the following words are reserved here but not in the core:
* BEGIN BY DECLARE EXECUTE FOREACH IF LOOP STRICT WHILE
This patch gets rid of EXECUTE and STRICT, but the others are harder
to de-reserve. I think most of the rest are there because they can
follow a block or loop label, and the same comment observes
* (We still have to reserve initial keywords that might follow a block
* label, unfortunately, since the method used to determine if we are at
* start of statement doesn't recognize such cases.
Looks so block label is a problem, but loop label not - and then BEGIN DECLARE WHEN is really required reserved world
by gram.y
Maybe these comments are a little bit obsolete. Probably is not a good idea to make unreserved words keywords used
as read_sql_xxxx delimiter: WHEN, LOOP, WHILE, INTO, USING, IN, FROM, and maybe some other. This is probably
main reason why PL/pgSQL has these keywords marked as reserved.
Maybe there should be a new assert, that checks so the keywords used as delimiters are reserved keywords.
I checked the list of reserved words of Ada language or PL/SQL language and we are significantly different.
I can imagine two situations.
a) current state + Tom's patch that reports so keywords are reserved
b) ignore the keyword after the "dot" symbol, and allow the reserved keyword as a record field without limits. SQL now allows using a lot of keywords as labels without
necessity of using AS or double quoting.
Both variants can work well I think - a) is more strict, zero invasive, b) is more user friendly, but small typo can hide some problems.
What do you think about it?
Regards
Pavel
regards, tom lane
