Alvaro Herrera wrote: > With that, pushed and I hope this is closed for good.
Great! I understand the fix couldn't be backpatched because we are not allowed to change the StringInfo struct in existing releases. But it occurs to me that the new "long_ok" flag might not be necessary after all now that it's settled that the length remains an int32. The flag is used to enforce a rule that the string can't normally grow past 1GB, and can reach 2GB only as an exception that we choose to exercise for COPY starting with v10. But that 1GB rule is never mentioned in stringinfo.[ch] AFAICS. I know that 1GB is the varlena size and is a limit for various things, but I don't know to what extent StringInfo is concerned by that. Is it the case that users of StringInfo in existing releases and extensions are counting on its allocator to fail and abort if the buffer grows over the varlena range? If it's true, then we're stuck with the current situation for existing releases. OTOH if this seems like a nonlegit expectation, couldn't we say that the size limit is 2^31 for all, and suppress the flag introduced by the fix? Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
