Hi, 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). 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). Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com