[EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match