Chapman Flack <chap@anastigmatix.net> writes:
> 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.
That seems like about 10X more complexity than is warranted,
not only in terms of the infrastructure required, but also in
the intellectual complexity around "just when could that value
change?"
Why not just provide equivalents to GetConfigOption() that can
deliver int, float8, etc values instead of strings?
(In any case we'd need to rethink the GUC "show_hook" APIs, which
currently need only deal in string output.)
regards, tom lane
