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

  1. Refactor function parse_subscription_options.

  2. Refactor function parse_output_parameters.

  3. Refactor option handling of CLUSTER, REINDEX and VACUUM

  4. Add assertion to quiet Coverity