Re: Underscore in positional parameters?

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Erik Wienhold <ewie@ewie.name>, Alexander Lakhin <exclusion@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Dean Rasheed <dean.a.rasheed@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-07-02T08:45:44Z
Lists: pgsql-hackers
On 02.07.24 10:14, Peter Eisentraut wrote:
> On 19.05.24 16:43, Erik Wienhold wrote:
>> On 2024-05-19 07:00 +0200, Alexander Lakhin wrote:
>>> I encountered anomalies that you address with this patch too.
>>> And I can confirm that it fixes most cases, but there is another one:
>>> SELECT $300000000 \bind 'foo' \g
>>> ERROR:  invalid memory alloc request size 1200000000
>>>
>>> Maybe you would find this worth fixing as well.
>>
>> Yes, that error message is not great.  In variable_paramref_hook we
>> check paramno > INT_MAX/sizeof(Oid) when in fact MaxAllocSize/sizeof(Oid)
>> is the more appropriate limit to avoid that unspecific alloc size error.
>>
>> Fixed in v4 with a separate patch because it's unrelated to the param
>> number parsing.  But it fits nicely into the broader issue on the upper
>> limit for param numbers.  Note that $268435455 is still the largest
>> possible param number ((2^30-1)/4) and that we just return a more
>> user-friendly error message for params beyond that limit.
> 
> I have committed your two v4 patches.
> 
> I made a small adjustment in 0001: I changed the ecpg part to also store 
> the result from strtoint() into a local variable before checking for 
> error, like you had done in the scan.l part.  I think this is a bit 
> better style.  In 0002 you had a typo in the commit message: MAX_INT 
> instead of INT_MAX.

I had to revert the test case from the 0002 patch.  It ended up running 
some build farm machines out of memory.




Commits

  1. Fix overflow in parsing of positional parameter

  2. Limit max parameter number with MaxAllocSize

  3. Re-forbid underscore in positional parameters