On Fri, Apr 19, 2024 at 10:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> One other bit of randomness that I noticed: ecpg's parse.pl has
> this undocumented bit of logic:
>
> if ($a eq 'IDENT' && $prior eq '%nonassoc')
> {
>
> # add more tokens to the list
> $str = $str . "\n%nonassoc CSTRING";
> }
> preproc.c has
>
> %nonassoc UNBOUNDED NESTED
> %nonassoc IDENT
> %nonassoc CSTRING PARTITION RANGE ROWS GROUPS PRECEDING FOLLOWING CUBE ROLLUP
> SET KEYS OBJECT_P SCALAR VALUE_P WITH WITHOUT PATH
> %left Op OPERATOR
>
> If you don't find that scary as heck, I suggest reading the very long
> comment just in front of the cited lines of gram.y. The argument why
> assigning these keywords a precedence at all is OK depends heavily
> on it being the same precedence as IDENT, yet here's ECPG randomly
> breaking that.
Before 7f380c59f (Reduce size of backend scanner's tables), it was
even more spread out:
# add two more tokens to the list
$str = $str . "\n%nonassoc CSTRING\n%nonassoc UIDENT";
...giving:
%nonassoc UNBOUNDED
%nonassoc IDENT
%nonassoc CSTRING
%nonassoc UIDENT GENERATED NULL_P PARTITION RANGE ROWS GROUPS
PRECEDING FOLLOWING CUBE ROLLUP
> We seem to have avoided problems though, because if I fix things
> by manually editing preproc.y to re-join the lines:
>
> %nonassoc IDENT CSTRING PARTITION RANGE ROWS GROUPS PRECEDING FOLLOWING CUBE ROLLUP
>
> the generated preproc.c doesn't change at all.
On a whim I tried rejoining on v12 and the .c doesn't change there, either.
> Actually, I can
> take CSTRING out of this list altogether and it still doesn't
> change the results ... although looking at how CSTRING is used,
> it looks safer to give it the same precedence as IDENT.
Doing that on v12 on top of rejoining results in a shift-reduce
conflict, so I imagine that's why it's there. Maybe it's outdated, but
this backs up your inclination that it's safer to keep.
