Re: Underscore in positional parameters?

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

In response to

Browse pgsql-hackers by date

  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