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