Stephen Frost escribió:
> * Alvaro Herrera ( wrote:
> > Well, all the relative paths in include/includedir directives would be
> > relative to the directory specified by the -c config_file param, which
> > makes perfect sense.  So the conf.d would work fine in your example.
> Why would include/includedir directives be relative to where the
> 'config_file' GUC is set to instead of relative to where all the other
> GUCs in postgresql.conf are relative to?  That is a recipe for
> confusion, imv.
> Of course, the current situation is quite terrible anyway, imv.  Having
> the GUCs be relative to whereever the user happens to run pg_ctl from is
> pretty ugly- not to mention that the commented out 'defaults' won't
> actually work if you uncomment them because the *actual* default/unset
> value *is* in the data directory.

Uh?  See the docs:

 " ... the postgresql.conf file can contain include directives, ...
  If the file name is not an absolute path, it is taken as relative to
  the directory containing the referencing configuration file."

> I'm starting to wish for a way to do
> variable substitution inside postgresql.conf, so we could have defaults
> that would actually work if uncommented (eg: $DataDir/pg_hba.conf).
> That would help with auto.conf also.

Grumble.  I don't think we need this.  At least, not for ALTER SYSTEM or

> > The only problem I see in your snippet above is the "include auto.conf"
> > line, which doesn't make any sense because that file would not be found.
> To be honest, I was considering 'include' to be relative to the data
> directory and handled similar to how we process recovery.conf,

Well, recovery.conf is a special case that doesn't follow to normal

> but as we
> consider paths in postgresql.conf to be relative to $PWD, that's not
> ideal because it'd be different from the rest of the file references.

I don't know where you got that idea from, but it's wrong.

> While I really like the 'include auto.conf' style, I'm starting to think
> it may not be workable after all.  Another thing to consider is if the
> user decides to change that include line..  What happens when the DBA
> tries to do a 'ALTER SYSTEM'?  It'd still use the hard-coded auto.conf
> file and happily update it, I imagine, but it won't actually get
> included...

Well, this whole line of discussion started because I objected to the
whole code path that was trying to detect whether auto.conf had been
parsed, and raised a warning if ALTER SYSTEM was executed and the file
wasn't parsed.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to