From: Tom Lane <tgl@sss.pgh.pa.us>
To: feikesteenbergen@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15555: Syntax errors when using the COMMENT command in
 plpgsql and a "comment" variable
In-reply-to: <31368.1545078376@sss.pgh.pa.us>
References: <15555-149bbd70ddc7b4b6@postgresql.org>
 <31368.1545078376@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 17 Dec 2018 15:26:16 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32113.1545079626.1@sss.pgh.pa.us>
Date: Mon, 17 Dec 2018 15:47:06 -0500
Message-ID: <32114.1545079626@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I wonder whether we could improve matters by adjusting the heuristic for
> such things in pl_scanner.c:
>
>              * If we are at start of statement, prefer unreserved keywords
>              * over variable names, unless the next token is assignment or
>              * '[', in which case prefer variable names.  (Note we need not
>              * consider '.' as the next token; that case was handled above,
>              * and we always prefer variable names in that case.)  If we are
>              * not at start of statement, always prefer variable names over
>              * unreserved keywords.

Digging in the commit history, that code all dates to commit bb1b8f69,
which arose from a discussion about making plpgsql keywords unreserved:

https://www.postgresql.org/message-id/5030.1416778830%40sss.pgh.pa.us

AFAICS, the question of conflicts against core-parser keywords didn't
come up at all in that thread, so it's not surprising we didn't consider
that case.  I don't see any indication that we explicitly rejected
doing something for that case.

There's still the question of whether there are any cases where we
*need* to recognize a variable name that's at statement start and
isn't followed by assignment or '['.

			regards, tom lane