I've been thinking more about how to fold the routines in variable.c
into the standard GUC structure. I think that we really want to do
this, so that (a) these parameters can be set from GUC sources such as
postgresql.conf, pg_database.datconfig, and pg_shadow.useconfig, and
(b) we only have to solve the SET-parameter-rollback issue once as
a generic GUC feature, not fix it for each of these special-case
variables too.
ISTM that we'd need to do the following:
1. Go back to a pure text-string-oriented interface to the per-variable
routines. Thomas' recent changes to make some of the variables have
a parsetree-based interface are okay as long as SETs coming from the
parser are all you worry about --- but for GUC there has to be a textual
equivalent that can be read from postgresql.conf or stored into
pg_database.datconfig/pg_shadow.useconfig. It seems to me to be cleanest
to flatten the parsetree down into a string and then let the per-variable
routines parse that back. It might waste a few cycles, but the
alternative is to support two interfaces (string and parsetree based)
throughout GUC. And we'll still need the parsing and flattening code
to support postgresql.conf and pg_database.datconfig --- so what's the
use of supporting two interfaces?
2. Add an optional "show" hook to GUC's set of per-variable hooks. If
present, this routine is called to produce the string that is used to
SHOW the variable, rather than simply repeating the stored value. I see
this as being mainly useful for the datestyle and timezone variables,
for which the show routine might emit info that's not present in the
most-recently-assigned input string --- but it might be used for any
variable that would like to emit a "canonical form" representation of
its value, rather than whatever was last passed to it.
A variant approach would be to allow the assign_hook to return a new
string that becomes the actually stored value string; this would amount
to performing the canonical-form calculation at assign time rather than
at show time. The show hook seems more general though, and less work
since existing assign_hook code wouldn't need to be touched.
Thoughts?
regards, tom lane
