From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Erik Wienhold <ewie(at)ewie(dot)name> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, peter(at)eisentraut(dot)org |
Subject: | Re: Underscore in positional parameters? |
Date: | 2024-05-15 04:27:10 |
Message-ID: | ZkQ5nvlTWsjJ6dWR@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-05-15 04:44:32 | Re: explain format json, unit for serialize and memory are different. |
Previous Message | Thomas Munro | 2024-05-15 04:21:25 | Re: Requiring LLVM 14+ in PostgreSQL 18 |