Re: Make StringInfo available to frontend code. - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Make StringInfo available to frontend code.
Date
Msg-id FAD46986-A46C-4A8D-87E5-40DA6B4852FB@yesql.se
Whole thread Raw
In response to Re: Make StringInfo available to frontend code.  (Andres Freund <andres@anarazel.de>)
Responses Re: Make StringInfo available to frontend code.  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
> 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.)

> I don't really think it's worth pointing out that they may not be
> consistent, when they currently are…

Good point.

> 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.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Dent John
Date:
Subject: Re: The flinfo->fn_extra question, from me this time.
Next
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: [PATCH] contrib/seg: Fix PG_GETARG_SEG_P definition