Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: robertmhaas@gmail.com
Cc: alvherre@alvh.no-ip.org, bharath.rupireddyforpostgres@gmail.com,
michael@paquier.xyz, smithpb2250@gmail.com, amit.kapila16@gmail.com,
sulamul@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2021-06-15T06:39:31Z
Lists: 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
Commits
-
Refactor function parse_subscription_options.
- 8aafb0261675 15.0 landed
-
Refactor function parse_output_parameters.
- 531737ddad21 14.0 cited
-
Refactor option handling of CLUSTER, REINDEX and VACUUM
- a3dc926009be 14.0 cited
-
Add assertion to quiet Coverity
- b1ff33fd9bb8 10.0 cited