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.
