Hi,
On 2019-11-02 23:57:06 +0100, Daniel Gustafsson wrote:
> > On 2 Nov 2019, at 03:21, Andres Freund <andres@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
