Re: Use an enum for RELKIND_*?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Use an enum for RELKIND_*?
Дата
Msg-id 10268.1545231322@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Use an enum for RELKIND_*?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Use an enum for RELKIND_*?  (Greg Stark <stark@mit.edu>)
Re: Use an enum for RELKIND_*?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-12-18 23:17:54 -0500, Tom Lane wrote:
>> Yeah, that would sure make things better.  I was considering
>> something like
>>
>>     #ifndef USE_ASSERT_CHECKING
>>         default:
>>             elog(ERROR, ...);
>>     #endif

> Yea, that's the best I can come up with too.  I think we'd probably want
> to have the warning available during development mainly, so I'm not sure
> the "lonely buildfarm animal" approach buys us enough.

Well, if it's controlled by some dedicated symbol ("CHECK_ENUM_SWITCHES"
or such) then you could certainly run a test compile with that turned
on, if you felt the need to.  But I don't really buy the complaint
that leaving it to the buildfarm to find such problems wouldn't work.
They're almost always simple, easily-fixed oversights.

Also, if we wrap all this up in a macro then it'd be possible to do
other things by adjusting the macro.  I'm envisioning

    switch ((RelationRelkind) rel->rd_rel->relkind)
    {
        case ...
        ...

        CHECK_ENUM_SWITCH(RelationRelkind, rel->rd_rel->relkind);
    }

where the macro expands to empty when you want compiler warnings,
or to something like

    default: elog(ERROR, "unsupported value %d of enum %s", ...)

in normal builds, or maybe some other way for special purposes.

(I guess pgindent would indent this as though it were part of the last
"case", which is slightly annoying, but if you leave a blank line
before it then that's probably fine.)

            regards, tom lane


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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Some memory allocations in gin fastupdate code are a bit brain dead
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: dropdb --force