Hello.
At Tue, 29 Oct 2019 19:06:38 -0700, Andres Freund <andres@anarazel.de> wrote in
> Hi,
>
> On 2019-10-30 10:58:59 +0900, Kyotaro Horiguchi wrote:
> > At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund <andres@anarazel.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,
Maybe so for doing that in this stage. So I expect that elog.h for FE
comes.
> the translation strings here would be more work than worthwhile. Also,
> do we even try to share the translations between backend and frontend?
No. I don't mean that. FE and BE have their own .po files, anyway.
> > > /* 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.
Ok, understoold. Thanks for the reply.
regards.
