From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | feikesteenbergen(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15555: Syntax errors when using the COMMENT command in plpgsql and a "comment" variable |
Date: | 2018-12-17 20:47:06 |
Message-ID: | 32114.1545079626@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-17 22:05:58 | Re: BUG #15555: Syntax errors when using the COMMENT command in plpgsql and a "comment" variable |
Previous Message | Tom Lane | 2018-12-17 20:31:07 | Re: BUG #15548: Unaccent does not remove combining diacritical characters |