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-01 22:19:33
Message-ID: 19042DF8-D486-4E8A-AA0E-88F691429773@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> Therefore it seems best to just making StringInfo being usable by
> frontend code. There's not much to do for that, except for rewriting
> two subsequent elog/ereport calls into others types of error
> reporting, and deciding on a maximum string length.

Skimming (but not testing) the patch, it seems a reasonable approach.

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

> 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/?

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-11-01 22:26:15 Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Previous Message Vik Fearing 2019-11-01 22:08:35 Re: Join Correlation Name