Re: Underscore in positional parameters? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Underscore in positional parameters?
Date
Msg-id ZkQ5nvlTWsjJ6dWR@paquier.xyz
Whole thread Raw
In response to Re: Underscore in positional parameters?  (Erik Wienhold <ewie@ewie.name>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Requiring LLVM 14+ in PostgreSQL 18
Next
From: David Rowley
Date:
Subject: Re: explain format json, unit for serialize and memory are different.