Re: Make StringInfo available to frontend code.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Make StringInfo available to frontend code.
Date: 2019-10-30 02:06:38
Message-ID: 20191030020638.znnlokh6edwcekup@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-10-30 10:58:59 +0900, Kyotaro Horiguchi wrote:
> 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.

I'm inclined to think that the contortions necessary to allow reusing
the translation strings here would be more work than worthwhile. Also,
do we even try to share the translations between backend and frontend?

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

No, I don't think so. I'd rather have less than more code depend on it.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-10-30 02:18:56 Re: Make StringInfo available to frontend code.
Previous Message Kyotaro Horiguchi 2019-10-30 01:58:59 Re: Make StringInfo available to frontend code.