Bruce Momjian <bruce@momjian.us> writes:
> However, in the case of custom variables, you are right that pg_settings
> doesn't show custom variables.
That is entirely intentional: the reason we do not show placeholder
variables in pg_settings is that we have no accurate information about
them, and so everything pg_settings might show would be fabricated,
and probably wrong, information.
Once the placeholder has been replaced by a proper declaration of the
GUC variable, it will be shown (with correct info), unless of course
the "proper declaration" includes GUC_NO_SHOW_ALL.
What this gets back to is that manually created "custom variables" are an
abuse of a loophole that was only meant to allow postgresql.conf to set
a parameter belonging to an extension module that hasn't been loaded yet.
If we want to actually support such variables, there should be a way to
properly declare one, including giving its type and other properties
... and ideally we'd not let you set one without having declared it,
though it's not quite clear how to enforce that without breaking the
parameter-placeholder case.
> We can do a few things:
> 1 show custom variables in SHOW ALL and pg_settings
> 2 show custom and other non-SHOW-ALL variables in pg_settings
> 3 document this restriction
or (4) fix the lack of a declaration capability. But both (1) and (2)
are horrid ideas. There are good reasons for having invented
GUC_NO_SHOW_ALL, and just trashing it is not the answer.
As for (3), I might be wrong, but I don't think the documentation mentions
the possibility of abusing SET this way at all. Restrictions in
undocumented quasi-features are likewise undocumented.
regards, tom lane
