Re: Make StringInfo available to frontend code.

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Make StringInfo available to frontend code.
Дата
Msg-id 20191030020638.znnlokh6edwcekup@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Make StringInfo available to frontend code.  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Make StringInfo available to frontend code.  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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@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,
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Make StringInfo available to frontend code.
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Make StringInfo available to frontend code.