From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Magnus Hagander" <magnus(at)hagander(dot)net>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: WIP: guc enums |
Date: | 2008-03-05 13:18:19 |
Message-ID: | 21019.1204723099@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> What I'd suggest is declaring the actual variable as int. You can still
>> use an enum typedef to declare the values, and just avert your eyes
>> when you have to cast the enum to int or vice versa. (This is legal per
>> C spec, so you won't introduce any portability issues when you do it.)
> That's pretty much the same as int variable and #defined constants. You
> lose compiler checks, like assigning from one enum type to another, and
> the "enumeration value FOOBAR not handled in switch" warning.
Well, you can at least get the latter if you cast explicitly:
switch ((MyEnum) myvariable) ...
We do this in several places already where the underlying variable isn't
declared as the enum for one reason or another. Also, local variables
can be declared as the enum type to get a little more safety.
In any case, the alternative being suggested of keeping the variables as
strings throws away *every* possible code-level advantage of having an
enum variable classification.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-03-05 13:33:09 | Re: WIP: guc enums |
Previous Message | Magnus Hagander | 2008-03-05 09:53:13 | Re: WIP: guc enums |