Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Smith <smithpb2250@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Amul Sul <sulamul@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-24T18:07:23Z
Lists: pgsql-hackers
On 2021-May-24, Bharath Rupireddy wrote: > On Mon, May 24, 2021 at 7:04 AM Michael Paquier <michael@paquier.xyz> wrote: > > What you are writing here and your comment two paragraphs above are > > inconsistent as you are using an enum here. Please see a3dc926 and > > the surrounding discussion for reasons why we've been using bitmaps > > for option parsing lately. > > Thanks! I'm okay to do something similar to what the commit a3dc926 > did using bits32. But I wonder if we will ever cross the 32 options > limit (imposed by bits32) for CREATE/ALTER SUBSCRIPTION command. > Having said that, for now, we can have an error similar to > last_assigned_kind in add_reloption_kind() if the limit is crossed. There's no API limitation here, since that stuff is not user-visible, so it doesn't matter. If we ever need a 33rd option, we can change the datatype to bits64. Any extensions using it will have to be recompiled across a major version jump anyway. -- Álvaro Herrera 39°49'30"S 73°17'W
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