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:14:23Z
Lists: pgsql-hackers
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.
Commits
-
Fix overflow in parsing of positional parameter
- d35cd0619984 18.0 landed
-
Limit max parameter number with MaxAllocSize
- 9c2e660b07fc 18.0 landed
-
Re-forbid underscore in positional parameters
- 315661ecafbc 16.4 landed
- 98b4f53d156e 17.0 landed