| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Smith <smithpb2250(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Amul Sul <sulamul(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options |
| Date: | 2021-05-24 18:07:23 |
| Message-ID: | 20210524180723.GA18372@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2021-May-24, Bharath Rupireddy wrote:
> On Mon, May 24, 2021 at 7:04 AM Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-05-24 18:21:04 | Re: Test of a partition with an incomplete detach has a timing issue |
| Previous Message | Alvaro Herrera | 2021-05-24 18:07:12 | Re: Test of a partition with an incomplete detach has a timing issue |