From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chapman Flack <chap(at)anastigmatix(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Mark all GUC variable as PGDLLIMPORT |
Date: | 2022-02-15 17:10:50 |
Message-ID: | 20220215171050.c63uueznsehjtb7w@jrouhaud |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2022-02-15 17:17:48 | Re: Mark all GUC variable as PGDLLIMPORT |
Previous Message | Andres Freund | 2022-02-15 17:09:52 | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |