Обсуждение: Why don't custom GUCs show in pg_settings?
Version - 9.5
O/S - not applicable
SELECT set_config('davidj.testvar', 'value');
SELECT current_setting('davidj.testvar') --value
SELECT * FROM pg_settings WHERE name ~ 'testvar' --or ~davidj... either way nothing shows
and:
SELECT current_setting('davidj.testvar2') -- unrecognized configuration parameter
The underlying goal is to use the custom GUC within a CREATE VIEW in a where clause. If the user issues a valid set_config for the GUC the query is appropriately filtered otherwise I set things up so that particular clause will not apply.
I've seen and can work with various work-arounds but it seems odd that pg_settings doesn't show these custom GUCs.
Is there a simple way to read the value without receiving an error if the value is missing?
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I've seen and can work with various work-arounds but it seems odd that
> pg_settings doesn't show these custom GUCs.
Because we don't know what type they should be.
If we're ever to support custom GUCs properly, rather than as a hack that
accidentally sorta works, there needs to be a way to declare them and
establish their properties; whereupon there would be info for pg_settings
to display.
> Is there a simple way to read the value without receiving an error if the
> value is missing?
See 10fb48d66, which I don't particularly approve of because it piled
another hack on top of that mess without doing a thing to make it cleaner.
regards, tom lane
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I've seen and can work with various work-arounds but it seems odd that
> pg_settings doesn't show these custom GUCs.
Because we don't know what type they should be.
If we're ever to support custom GUCs properly, rather than as a hack that
accidentally sorta works, there needs to be a way to declare them and
establish their properties; whereupon there would be info for pg_settings
to display.
It seems that a "reasonable defaults" policy would be better than nothing...though given the "missing_ok" feature the work-around with pg_settings isn't needed.
The existing set_config would setup the text-oriented defaults while, if someone cares enough, a set_custom_config (or overloaded set_config) function could be written that would allow specifying stuff like description, unit, initial value, etc.
But what amounts to a session-local hstore seem, whose contents are displayed in pg_settings along with the system GUCs, and is documented, seems like an adequate feature to acknowledge officially.
> Is there a simple way to read the value without receiving an error if the
> value is missing?
See 10fb48d66, which I don't particularly approve of because it piled
another hack on top of that mess without doing a thing to make it cleaner.
Thanks.
I recalled seeing that, just didn't remember that it is new to 9.6 - I only looked at the 9.5 documentation and didn't see it.
David J.