Re: BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Leendert Gravendeel <leenderthenk(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause
Date: 2026-04-17 15:16:20
Message-ID: 3068556.1776438980@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Leendert Gravendeel <leenderthenk(at)gmail(dot)com> writes:
> When using FOREACH with the SLICE clause, a loop variable named
> `slice` is misinterpreted as the SLICE keyword, causing the statement
> to fail. Renaming the variable to anything else makes the function
> work as expected.

So, um, don't do that. PL/pgSQL will let you use (many of) its keywords
as variable names, but once you declare such a variable, the word will
be taken as a variable reference not as a keyword for the rest of the
block. So what the parser is seeing here is

FOREACH variable variable 1 IN ARRAY variable LOOP

and it naturally doesn't like that. You could also break this
statement by making a variable named "array", for example.
(But not "foreach", "in", or "loop", as those are reserved words.)

Not sure how well this behavior is documented. I think there are
a small number of exceptions, in places where the scanner can know
that the next word must be a keyword, but most unreserved keywords
work this way. The only other thing we could do is make such keywords
fully reserved, which would break legacy code that uses "slice" or
whatever as a variable name without knowledge of the new SLICE syntax.
So we generally try to make newly-added keywords unreserved; this
ambiguity seems the lesser evil.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2026-04-17 15:17:52 Re: BUG: PL/pgSQL FOREACH misparses variable named "slice" with SLICE clause
Previous Message PG Bug reporting form 2026-04-17 11:20:34 BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables