Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options |
Дата | |
Msg-id | 20210615.153931.1368564125027634013.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
At Fri, 11 Jun 2021 16:29:10 -0400, Robert Haas <robertmhaas@gmail.com> wrote in > On Tue, May 25, 2021 at 9:38 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > This should be okay, right? Well, almost. The problem here is if you > > want to have a variable where you set more than one option, you have to > > use bit-and of the enum values ... and the resulting value is no longer > > part of the enum. A compiler would be understandably upset if you try > > to pass that value in a variable of the enum datatype. > > Yes. I dislike this style for precisely this reason. > > I may, however, be in the minority. I personaly don't hate that so much, but generally an "enumeration" type is considered to be non-numbers. That is, no arithmetics are defined between two enum values. I think that C being able to perform arithmetics on enums is just for implement reasons. I think that arithmetics (logical operations are not arithmetics?) between boolean values are for the same reasons. Actually Java refuses arithmetics on enum values. > hoge.java:27: error: bad operand types for binary operator '+' > int x = theenum.x + theenum.z; > ^ > first type: theenum > second type: theenum regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: