Re: [HACKERS] Configuration patch

pgsql@mohawksoft.com wrote:
> >> I wanted to create a generic facility for "smarter" configuration. Being
> >> able to create functions and pass parameters should allow smaller more
> >> focused configuration parsing.
> >
> > I don't believe "include" is a representative of a class; it seems a
> > specialized one-of-a-kind thing.  If you had one or two more examples
> > of this class then I might think you are onto something, but as-is
> > there is no reason to think that you've got a well-defined idea or
> > have made the right decisions about how it should work.
>
> OK, imagine this, maybe not right now, but in the future......
>
> In the configuration file, one can load C code modules like in apache. Not
> just SQL functions, but modules of functionality, like foreign table
> types.

I agree with Tom that "include" isn't really a setting, but more of an
action.  What would "SHOW include" output?  I think that outlines why it
is different from other setttings.  Your "load" capability would be
another non-setting, or perhaps a read-only one, but not the same as
include either.  Include includes other settings.

One format idea would be to suppress the equals for include, so:

    include '/somedir/pgdefs.conf'              # include another file
    hba_conf = '/etc/postgres/pg_hba.conf'      # use file in another directory
    ident_conf = '/etc/postgres/pg_ident.conf'  # use file in another directory
    pgdata = '/usr/local/pgsql/data'            # use /data in another directory
    external_pidfile= '/var/run/postgresql.pid' # write an extra pid file

Notice include has no equals.  This would more clearly suggest that
multiple includes could be used.  I think a SHOW of include should
report an error.

One interesting idea would be for "SET include" to work like this:

    SET include '/var/run/xx'

Notice there is no equals here.  This would allow users to create files
with various settings and enable them all with one SET command.
However, this does open a security issue.  Seems we might have to
disallow this and only allow include in postgresql.conf, where the
super-user has full control.

I agree with Tom that the documentation is sparse.  Hopefully folks can
add to that.  If someone is going to keep improving this patch, please
use the version I posted rather than the original because mine has lots
of cleanups.

    ftp://candle.pha.pa.us/pub/postgresql/mypatches/guc

In summary, I think we need to treat include specially in
postgresql.conf (no equals) and remove it as an actual GUC parameter and
just have it do includes immediately.  (This will probably require
special-casing it in the guc-file grammar.)  Also, we need more docs on
how to set up the new -D/PGDATA functionality.  I was wondering myself
how someone would configure this.  Do we need to add an initdb
capability?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073