Hi, On Sat, Apr 11, 2026 at 10:04 AM Amit Kapila <[email protected]> wrote: > > On Fri, Mar 20, 2026 at 2:08 PM Ashutosh Sharma <[email protected]> wrote: > > > > On Fri, Mar 20, 2026 at 1:21 PM Hou, Zhijie/侯 志杰 <[email protected]> > > 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. >
That sounds like a good approach. I’ll split the current patch into two parts, with support for the ANY-based syntax being the first patch, and share it. -- With Regards, Ashutosh Sharma.
