On Wed, Feb 16, 2022 at 01:10:50AM +0800, Julien Rouhaud wrote:
> Hi,
>
> On Mon, Feb 14, 2022 at 12:45:08PM -0500, Robert Haas wrote:
> > On Mon, Feb 14, 2022 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > > * There's a moderately sizable subset of GUCs where the underlying
> > > variable is not visible at all because it's static in guc.c.
> > > Typically this is because that variable is only used for display
> > > and there's an assign hook that stores the real data somewhere else.
> > > I suppose what we want in such cases is for the "somewhere else"
> > > to be PGDLLIMPORT'd, but in a lot of cases those variables are also
> > > static in some other module. Does this proposal include exporting
> > > variables that currently aren't visible to extensions at all?
> > > I'm a little resistant to that. I can buy making sure that Windows
> > > has a level playing field, but that's as far as I want to go.
> >
> > I can live with that. If someone complains about those variables being
> > static-to-file instead of globally visible, we can address that
> > complaint on its merits when it is presented.
>
> Same here, if any third-party project had any use of such variable, they would
> have sent some patch for that already so I don't see any reason to change it
> now.
Agreed. I think the big goal here is to make Windows have the same
GUC variable visibility as Unix --- when we change things in a way that
breaks extensions, we hear about Unix breakage quickly and adjust for
it. It is Windows being different and only getting the problem reports
later that is the real problem.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
