On Tue, Sep 10, 2024 at 8:56 PM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > On Mon, Sep 09, 2024 at 04:24:09PM +0530, Amit Kapila wrote: > > On Fri, Aug 30, 2024 at 5:18 PM Bertrand Drouvot > > <bertranddrouvot...@gmail.com> wrote: > > > as we decided not to expose the SnapBuildOnDisk and SnapBuild structs to > > > public > > > and to create/expose 2 new functions in snapbuild.c then the functions in > > > the > > > module would do nothing but expose the data coming from the snapbuild.c's > > > functions (get the tuple and send it to the client). That sounds weird to > > > me to > > > create a module that would "only" do so, that's why I thought that in core > > > functions taking care of everything make more sense. > > > > > > > I see your point. Does anyone else have an opinion on the need for > > these functions and whether to expose them from a contrib module or > > have them as core functions? > > I looked at when the SNAPBUILD_VERSION has been changed: > > ec5896aed3 (2014) > a975ff4980 (2021) > 8bdb1332eb (2021) > 7f13ac8123 (2022) > bb19b70081 (2024) > > So it's not like we are changing the SnapBuildOnDisk or SnapBuild structs that > frequently. Furthermore, those structs are serialized and so we have to > preserve > their on-disk compatibility (means we can change them only in a major release > if we need to). > > So, I think it would not be that much of an issue to expose those structs and > create a new contrib module (as v1 did propose) instead of in core new > functions. > > If we want to insist that external modules "should" not rely on those structs > then > we could put them into a new internal_snapbuild.h file (instead of snapbuild.h > as proposed in v1). >
Adding snapbuild_internal.h sounds like a good idea. > At the end, I think that creating a contrib module and exposing those structs > in > internal_snapbuild.h make more sense (as compared to in core functions). > Fail enough. We can keep the module name as logicalinspect so that we can extend it for other logical decoding/replication-related files in the future. -- With Regards, Amit Kapila.
