Hi, On 2019-11-02 23:57:06 +0100, Daniel Gustafsson wrote: > > On 2 Nov 2019, at 03:21, Andres Freund <and...@anarazel.de> wrote: > > On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote: > > >> + * StringInfo provides an extensible string data type. It can be used to > >> > >> It might be useful to point out the upper bound on the extensibility in the > >> rewrite of this sentence, and that it’s not guaranteed to be consistent > >> between > >> frontend and backend. > > > > Hm. Something like 'Currently the maximum length of a StringInfo is > > 1GB.’? > > Something along those lines (or the define/mechanism with which the upper > boundary controlled, simply stating the limit seems more straightforward.)
Pushed now, with a variation of my suggestion above. As nobody commented on that, I've not adjusted the location of stringinfo.h. If somebody has feelings about it being in the wrong place, and whether to put a redirecting header in place, or whether to just break extensions using stringinfo, ... > > And I suspect we should just fix the length limit to be higher for both, > > perhaps somehow allowing to limit the length for the backend cases where > > we want to error out if a string gets too long (possibly adding a > > separate initialization API that allows to specify the memory allocation > > flags or such). > > Sounds reasonable, maybe even where one can set errhint/errdetail on the “out > of memory” error to get better reporting on failures. That seems too much customization for the caller / too much added complexity, for the little gain it'd provide. Normally if a caller wants something like that, they can push something onto the error context stack, and get context information out that way. Greetings, Andres Freund