Re: making the backend's json parser work in frontend code

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: making the backend's json parser work in frontend code
Дата
Msg-id 13142.1580229297@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: making the backend's json parser work in frontend code  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: making the backend's json parser work in frontend code
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 28, 2020 at 10:30 AM Mahendra Singh Thalor
> <mahi6run@gmail.com> wrote:
>> Tom Lane already fixed this and committed yesterday(4589c6a2a30faba53d0655a8e).

> Oops. OK, thanks.

Yeah, there were multiple issues here:

1. If a switch is expected to cover all values of an enum type,
we now prefer not to have a default: case, so that we'll get
compiler warnings if somebody adds an enum value and fails to
update the switch.

2. Without a default:, though, you need to have after-the-switch
code to catch the possibility that the runtime value was not a
legal enum element.  Some compilers are trusting and assume that
that's not a possible case, but some are not (and Coverity will
complain about it too).

3. Some compilers still don't understand that elog(ERROR) doesn't
return, so you need a dummy return.  Perhaps pg_unreachable()
would do as well, but project style has been the dummy return for
a long time ... and I'm not entirely convinced by the assumption
that every compiler understands pg_unreachable(), anyway.

(I know Robert knows all this stuff, even if he momentarily
forgot.  Just summarizing for onlookers.)

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: making the backend's json parser work in frontend code
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [Proposal] Global temporary tables