Re: Make StringInfo available to frontend code.

At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> Hi,
>
> This patch, in a slightly rougher form, was submitted as part of [1],
> but it seems worth bringing up separately, rather than just committing
> hearing no objections.
..
> 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.
>
> I also would like to submit a few patches expanding stringinfo's
> capabilities and performance, and it seems to me it'd be better to do so
> after moving (lest they introduce new FE vs BE compat issues).
>
>
> This allows us to remove compat.c hackery providing some stringinfo
> functionality for pg_waldump (which now actually needs to pass in a
> StringInfo...). I briefly played with converting more code in
> pg_waldump.c than just that one call to StringInfo, but it seems that'd
> be best done separately.
>
> Comments?

It uses different form for the same message for FE and BE.

common/stringinfo.c:289-
> BE: ereport(ERROR,
> (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> errmsg("out of memory"),
> errdetail("Cannot enlarge string buffer containing %d
> bytes by %d more bytes.",
>
> FE: + _("out of memory\n\nCannot enlarge string buffer containing %d
> bytes by %d more bytes.\n"),

.po files will be smaller and more stable if we keep the same
translation unit for the same messages. That being said it doesn't
matter if it is tentative and the minimal elog.h for frontend comes
soon.

> /* It's possible we could use a different value for this in frontend code */
> #define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */

The same symbol is defined for frontend in psprint.c. Isn't it better
merge them and place it in postgres_fe.h?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center