Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Date
Msg-id 20210524180723.GA18372@alvherre.pgsql
Whole thread Raw
In response to Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Test of a partition with an incomplete detach has a timing issue
Next
From: Tom Lane
Date:
Subject: Re: Test of a partition with an incomplete detach has a timing issue