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).
I'm not terribly sure about enlargeStringInfo(). I think I would propose that it takes Size instead of int. That has rather more fallout than I'd like, but if we don't do that, then I'm not sure that appendStringInfo continues to makes sense -- considering that it uses the return value from appendStringInfoVA (which I'm redefining as returning Size) to pass to enlargeStringInfo. I'm not really sure how to ensure that the values passed fit both in an int and Size ... which they would, given that all the callers use not-huge stringinfos anyway. But it'd be better if the compiler knew. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers