Re: Underscore in positional parameters?
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Erik Wienhold <ewie@ewie.name>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Dean Rasheed <dean.a.rasheed@gmail.com>, pgsql-hackers@postgresql.org, peter@eisentraut.org
Date: 2024-05-15T04:27:10Z
Lists: pgsql-hackers
On Tue, May 14, 2024 at 06:07:51PM +0200, Erik Wienhold wrote:
> I split the change in two independent patches:
The split makes sense to me.
> Patch 0001 changes rules param and param_junk to only accept digits 0-9.
-param \${decinteger}
-param_junk \${decinteger}{ident_start}
+/* Positional parameters don't accept underscores. */
+param \${decdigit}+
+param_junk \${decdigit}+{ident_start}
scan.l, psqlscan.l and pgc.l are the three files impacted, so that's
good to me.
> Patch 0002 replaces atol with pg_strtoint32_safe in the backend parser
> and strtoint in ECPG. This fixes overflows like:
>
> => PREPARE p1 AS SELECT $4294967297; -- same as $1
> PREPARE
>
> It now returns this error:
>
> => PREPARE p1 AS SELECT $4294967297;
> ERROR: parameter too large at or near $4294967297
This one is a much older problem, though. What you are doing is an
improvement, still I don't see a huge point in backpatching that based
on the lack of complaints with these overflows in the yyac paths.
+ if (errno == ERANGE)
+ mmfatal(PARSE_ERROR, "parameter too large");
Knowong that this is working on decdigits, an ERANGE check should be
enough, indeed.
--
Michael
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