On Saturday, April 11, 2026 12:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Mar 20, 2026 at 2:08 PM Ashutosh Sharma <ashu.coek88@gmail.com>
> wrote:
> >
> > On Fri, Mar 20, 2026 at 1:21 PM Hou, Zhijie/侯 志杰
> <houzj.fnst@fujitsu.com> wrote:
> > >
> > > Since we're reusing the same parser for two GUCs that have different
> > > interpretations of one syntax variant (the plain slot list), making
> > > the parser more general is a natural approach, especially given that
> > > the patch is adding new functionality here.
> > >
> > > My main concern is the IsPrioritySyncStandbySlotsSyntax() function.
> > > It introduces additional hard-coded parsing logic that duplicates
> > > what's already implemented in syncrep_gram.y. I'm also concerned
> > > about maintainability, particularly since we already discovered a
> > > bug in the hard-coded parser code [1] and the patch even added a
> > > tap-test (part E) to cover that path. All of this effort could be
> > > avoided by removing this function and leveraging functionality provided by
> the shared parser.
> > >
> >
> > The issue that you are referring to here was without this function.
> >
> > The idea here is to reuse the existing synchronous_standby_names
> > parser as-is, without changing its grammar or parse behavior.
> > synchronized_standby_slots differs only in post-parse interpretation
> > of simple-list syntax, so we add a local helper to disambiguate
> > explicit priority mode from plain lists before applying
> > synchronized_standby_slots semantics.
> >
>
> How about splitting the patch to separate out the ANY configuration as the
> first patch? Then we can focus on the FIRST configuration separately and it
> would be easier to evaluate whether changing the parser for it is worth the
> additional complexity.
+1
For reference only, I'm attaching a top-up patch (on top of v20260408-0001) that
refactors the parsing logic to distinguish between FIRST and plain lists, as
previously discussed.
Best Regards,
Hou zj
