From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | andres(at)anarazel(dot)de |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Use an enum for RELKIND_*? |
Date: | 2018-12-19 02:19:34 |
Message-ID: | 20181219.111934.129809370.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello.
At Tue, 18 Dec 2018 17:13:08 -0800, Andres Freund <andres(at)anarazel(dot)de> wrote in <20181219011308(dot)mopzyvc73nwjzdb6(at)alap3(dot)anarazel(dot)de>
> Hi,
>
> Right now there's no easy way to use the compiler to ensure that all
> places that need to deal with all kinds of relkinds check a new
> relkind. I think we should make that easier by moving RELKIND_* to an
> enum, with the existing letters as the value.
I feel the same pain and I had thought of a kind of that before.
> Obviously we cannot really do that for FormData_pg_class.relkind, but
> switch() statements can easily cast that to RelationRelkind (or whatever
> we name it).
>
> Does anybody see a reason not to do so?
I think we cannot use enums having base-type, so it will work
unless we forget the cast within switch(). However, I don't think
it is not a reason not to do so.
switch ((RelationRelkind) rel->rd_rel->relkind)
{
...
}
char is compatible with integer under our usage there. FWIW I
don't mind explict assignments in the enum definition since we
already do the similar thing there.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-19 03:50:57 | Re: Use an enum for RELKIND_*? |
Previous Message | Andres Freund | 2018-12-19 01:13:08 | Use an enum for RELKIND_*? |