Re: Underscore in positional parameters?
От | Peter Eisentraut |
---|---|
Тема | Re: Underscore in positional parameters? |
Дата | |
Msg-id | 8b78ca85-9b90-4b6b-86c7-9792377138a9@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Underscore in positional parameters? (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Underscore in positional parameters?
Re: Underscore in positional parameters? |
Список | 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.
В списке pgsql-hackers по дате отправления: