Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Дата
Msg-id CALj2ACXWB7savBeS0qHpQ0VZbN-bs9Qp425MW3v2HCN5rR7a_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options  (Amul Sul <sulamul@gmail.com>)
Ответы Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Wed, May 19, 2021 at 2:33 PM Amul Sul <sulamul@gmail.com> wrote:
>
> On Wed, May 19, 2021 at 2:09 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >
> > Hi,
> >
> > parse_subscription_options function has some similar code when
> > throwing errors [with the only difference in the option]. I feel we
> > could just use a variable for the option and use it in the error.
> > While this has no benefit at all, it saves some LOC and makes the code
> > look better with lesser ereport(ERROR statements. PSA patch.
> >
> > Thoughts?
>
> I don't have a strong opinion on this, but the patch should add
> __translator__ help comment for the error msg.

Is the "/*- translator:" help comment something visible to the user or
some other tool? If not, I don't think that's necessary as the meaning
of the error message is evident by looking at the error message
itself. IMO, anyone who looks at that part of the code can understand
it.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Different compression methods for FPI
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: libpq_pipeline in tmp_install