Alvaro Herrera wrote:
> I propose to rename allow_long to huge_ok. "Huge" is the terminology
> used by palloc anyway. I'd keep makeLongStringInfo() and
> initLongStringInfo() though as interface, because using Huge instead of
> Long there looks strange. Not wedded to that, though (particularly as
> it's a bit inconsistent).
"Long" makes sense to me as qualifying a limit greater than
MaxAllocSize but lower (or equal) than MaxAllocHugeSize.
In memutils.h we have these definitions:
#define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
#define MaxAllocHugeSize ((Size) -1 >> 1) /* SIZE_MAX / 2 */
And in enlargeStringInfo() the patch adds this:/* * Maximum size for strings with allow_long=true. * It must not exceed
INT_MAX,as the StringInfo routines * expect offsets into the buffer to fit into an int. */const int max_alloc_long =
0x7fffffff;
On a 32-bit arch, we can expect max_alloc_long == MaxAllocHugeSize,
but on a 64-bit arch, it will be much smaller with MaxAllocHugeSize
at (2^63)-1.
IOW, the patch only doubles the maximum size of StringInfo
whereas we could say that it should multiply it by 2^32 to pretend to
the "huge" qualifier.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite