Re: Mark all GUC variable as PGDLLIMPORT

Hi,

On 02/13/22 02:29, Julien Rouhaud wrote:
> Maybe we could have an actually usable GUC API to retrieve values in their
> native format rather than C string for instance, that we could make sure also
> works for cases like max_backend?

I proposed a sketch of such an API for discussion back in [0] (the second
idea in that email, the "what I'd really like" one).

In that scheme, some extension code that was interested in (say,
for some reason) log_statement_sample_rate could say:

static double samprate;
static int gucs_changed = 0;

#define SAMPRATE_CHANGED 1

...
ObserveTypedConfigValue("log_statement_sample_rate",
&samprate, &gucs_changed, SAMPRATE_CHANGED);
...

and will be subscribed to have the native-format value stored into samprate,
and SAMPRATE_CHANGED ORed into gucs_changed, whenever the value changes.

The considerations leading me to that design were:

- avoid subscribing as a 'callback' sort of listener. GUCs can get set
(or, especially, reset) in delicate situations like error recovery
where calling out to arbitrary extra code might best be avoided.

- instead, just dump the value in a subscribed location. A copy,
of course, so no modification there affects the real value.

- but at the same time, OR a flag into a bit set, so subscribing code can
very cheaply poll for when a value of interest (or any of a bunch of
values of interest) has changed since last checked.

- do the variable lookup by name once only, and pay no further search cost
when the subscribing code wants the value.

I never pictured that proposal as the last word on the question, and
different proposals could result from putting different weights on those
objectives, or adding other objectives, but I thought it might serve
as a discussion-starter.

Regards,
-Chap

[0] https://www.postgresql.org/message-id/6123C425.3080409%40anastigmatix.net