From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Mark all GUC variable as PGDLLIMPORT |
Date: | 2022-02-13 20:48:18 |
Message-ID: | 20220213204818.sct73jkfxpbxy7sg@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-02-13 15:36:16 -0500, Chapman Flack wrote:
> Clearly I'm not thinking here of the GUCs that are read-only views of
> values that are determined some other way. How many of those are there
> that are mutable, and could have their values changed without going
> through the GUC mechanisms?
Is there any GUCs where one needs this? There are a few GUCs frequently
changing values, but it's stuff like transaction_read_only. Where I don't
really see a use for constantly checking the value.
> Also, I think there are some options that are only represented by
> an int, float8, etc., when shown, but whose native internal form
> is something else, like a struct. I was definitely contemplating
> that you could 'subscribe' to one of those too, by passing the
> address of an appropriate struct. But of course a GetConfigOption()
> flavor could work that way too.
I have a very hard time seeing a use-case for this. Nor how it'd even work
with a struct - you can't just copy the struct contents, because of pointers
to objects etc. I don't think there really are options like this anyway.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-13 20:48:44 | Re: Mark all GUC variable as PGDLLIMPORT |
Previous Message | Andres Freund | 2022-02-13 20:42:05 | Re: fixing bookindex.html bloat |