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