Re: Underscore in positional parameters?

On 2024-05-14 16:40 +0200, Tom Lane wrote:
> 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.

I split the change in two independent patches:

Patch 0001 changes rules param and param_junk to only accept digits 0-9.

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
    => EXECUTE p1 (123);
     ?column?
    ----------
     123
    (1 row)

    => PREPARE p2 AS SELECT $2147483648;
    ERROR:  there is no parameter $-2147483648
    LINE 1: PREPARE p2 AS SELECT $2147483648;

It now returns this error:

    => PREPARE p1 AS SELECT $4294967297;
    ERROR:  parameter too large at or near $4294967297

    => PREPARE p2 AS SELECT $2147483648;
    ERROR:  parameter too large at or near $2147483648

-- 
Erik