On Sat, Apr 25, 2026 at 1:51 AM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Fri, Apr 24, 2026 at 12:17 AM shveta malik <[email protected]> wrote: > > > > > What about introducing a publication_tables_state struct stored in > > > user_fctx > > > that carries both the list and a private position index? (kind of what > > > pg_timezone_abbrevs_zone() is doing). > > > > Yeah, that is a good idea. Seems doable. > > +1. Thanks for the pointer. Adding a new struct to carry both the > table_infos and the current index into it seems simple with a smaller > diff. > > If I were to think of another approach (I don't prefer this approach > anyway), we could convert pg_get_publication_tables from the current > value-per-call SRF function (SRF_IS_FIRSTCALL + SRF_RETURN_NEXT) to a > materialized SRF function (InitMaterializedSRF + > tuplestore_putvalues). With a materialized SRF function, there is no > need to add a new structure or maintain per-call context - table_infos > becomes a local variable, and we skip placing anything related to > dropped tables into the tuplestore immediately in the second loop (the > first loop remains the same, preparing the table_infos list). This > approach seems more complex with a larger diff and requires use of > InitMaterializedSRF for versions >= PG16, SetSingleFuncCall for PG15, > and for PG14 requires inlining SetSingleFuncCall. > > I prefer adding the new struct to carry both table_infos and the > current index into it with the current value-per-call SRF function, > unless others have better ideas.
+1. It is simpler than the Materialization concept. > If okay, I will send a new patch > soon. Thank you! > Sure, Thanks! thanks Shveta
