Re: Make StringInfo available to frontend code.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Make StringInfo available to frontend code.
Date: 2019-11-02 02:21:18
Message-ID: 20191102022118.r2o3zmls73s5usum@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote:
> > On 30 Oct 2019, at 01:10, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > Make StringInfo available to frontend code.
>
> I’ve certainly wanted just that on multiple occasions, so +1 on this.

Cool.

> + * 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.'? I don't really think it's worth pointing out that they may not be
consistent, when they currently are...

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

> > I'm still using stringinfo in the aforementioned thread, and I also want
> > to use it in a few more places. On the more ambitious side I really
> > would like to have a minimal version of elog.h available in the backend,
> > and that would really be a lot easier with stringinfo available.
>
> s/backend/frontend/?

Indeed.

Thanks for looking,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-11-02 02:47:26 Re: Remove configure --disable-float4-byval and --disable-float8-byval
Previous Message vignesh C 2019-11-02 02:12:06 Re: Ordering of header file inclusion