Re: Underscore in positional parameters?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Erik Wienhold <ewie@ewie.name>,
pgsql-hackers@postgresql.org, peter@eisentraut.org
Date: 2024-05-14T14:40:39Z
Lists: pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Tue, 14 May 2024 at 07:43, Michael Paquier <michael@paquier.xyz> wrote:
>> On Tue, May 14, 2024 at 05:18:24AM +0200, Erik Wienhold wrote:
>>> Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
>>> the parameter number with atol which stops at the underscore. That's a
>>> regression in faff8f8e47f. Before that commit, $1_2 resulted in
>>> "ERROR: trailing junk after parameter".
> I'm sure that this wasn't intentional -- I think we just failed to
> notice that "param" also uses "decinteger" in the scanner. Taking a
> quick look, there don't appear to be any other uses of "decinteger",
> so at least it only affects params.
> Unless the spec explicitly says otherwise, I agree that we should
> reject this, as we used to do, and add a comment saying that it's
> intentionally not supported. I can't believe it would ever be useful,
> and the current behaviour is clearly broken.
+1, let's put this back the way it was.
regards, tom lane
Commits
-
Fix overflow in parsing of positional parameter
- d35cd0619984 18.0 landed
-
Limit max parameter number with MaxAllocSize
- 9c2e660b07fc 18.0 landed
-
Re-forbid underscore in positional parameters
- 315661ecafbc 16.4 landed
- 98b4f53d156e 17.0 landed