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.
--
With Regards,
Amit Kapila.
