Re: Underscore in positional parameters?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Erik Wienhold <ewie@ewie.name>, pgsql-hackers@postgresql.org, peter@eisentraut.org
Date: 2024-05-14T14:40:39Z
Lists: pgsql-hackers
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.

			regards, tom lane



Commits

  1. Fix overflow in parsing of positional parameter

  2. Limit max parameter number with MaxAllocSize

  3. Re-forbid underscore in positional parameters