Re: Make StringInfo available to frontend code.

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Make StringInfo available to frontend code.
Date: 2019-11-02 22:57:06
Message-ID: FAD46986-A46C-4A8D-87E5-40DA6B4852FB@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 2 Nov 2019, at 03:21, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2019-11-02 23:14:47 [PATCH] contrib/seg: Fix PG_GETARG_SEG_P definition
Previous Message Dent John 2019-11-02 22:42:56 Re: The flinfo->fn_extra question, from me this time.