Skip site navigation (1) Skip section navigation (2)

Folding variable.c into the GUC structure, redux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>,Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Folding variable.c into the GUC structure, redux
Date: 2002-04-29 18:05:39
Message-ID: (view raw or flat)
Lists: pgsql-hackers
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.


			regards, tom lane

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2002-04-29 18:10:13
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Hannu KrosingDate: 2002-04-29 17:47:54
Subject: Re: Vote totals for SET in aborted transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group