Re: Patch for 9.1: initdb -C option - Mailing list pgsql-hackers

David,

I'd like to volunteer reviewing your patch at first in this commit fest.

We already had a few comments on the list before. I want to see your
opinion for the suggestions prior to code reviews.

Itagaki-san suggested:
| > Enclosed is a patch to add a -C option to initdb to allow you to easily
| > append configuration directives to the generated postgresql.conf file
| Why don't you use just "echo 'options' >> $PGDATA/postgresql.conf" ?
| Could you explain where the -C options is better than initdb + echo?

Greg suggested:
| We had a patch not quite make it for 9.0 that switched over the postgresql.conf
| file to make it easy to scan a whole directory looking for configuration files:
| http://archives.postgresql.org/message-id/9837222c0910240641p7d75e2a4u2cfa6c1b5e603d84@mail.gmail.com
|
| The idea there was to eventually reduce the amount of postgresql.conf hacking
| that initdb and other tools have to do.  Your patch would add more code into
| a path that I'd like to see reduced significantly.
|
| That implementation would make something easy enough for your use case too
| (below untested but show the general idea):
|
| $ for cluster in 1 2 3 4 5 6;
|  do initdb -D data$cluster
|  (
|  cat <<EOF
|  port = 1234$cluster;
|  max_connections = 10;
|  shared_buffers=1M;
|  EOF
|  ) > data$cluster/conf.d/99clustersetup
| done
|
| This would actually work just fine for what you're doing right now if you used
| ">> data$cluster/postgresql.conf" for that next to last line there.
| There would be duplicates, which I'm guessing is what you wanted to avoid with
| this patch, but the later values set for the parameters added to the end would
| win and be the active ones.

Peter suggested:
| > Enclosed is a patch to add a -C option to initdb to allow you to easily
| > append configuration directives to the generated postgresql.conf file
| > for use in programmatic generation.
| I like this idea, but please use small -c for consistency with the
| postgres program.

It seems to me what Greg suggested is a recent trend. Additional configurations
within separated files enables to install/uninstall third-party plugins easily
from the perspective of packagers, rather than consolidated configuration.

However, $PGDATA/postgresql.conf is created on initdb, so it does not belong
to a certain package. I don't have certainty whether the recent trend is also
suitable for us, or not.

Thanks,

(2010/03/29 14:04), David Christensen wrote:
> Hackers,
> 
> Enclosed is a patch to add a -C option to initdb to allow you to easily append configuration directives to the
generatedpostgresql.conf file for use in programmatic generation.  In my case, I'd been creating multiple db clusters
witha script and would have specific overrides that I needed to make.   This patch fell out of the desire to make this
alittle cleaner.  Please review and comment.
 
> 
>  From the commit message:
> 
>      This is a simple mechanism to allow you to provide explicit overrides
>      to any GUC at initdb time.  As a basic example, consider the case
>      where you are programmatically generating multiple db clusters in
>      order to test various configurations:
> 
>        $ for cluster in 1 2 3 4 5 6;
>        >    do initdb -D data$cluster -C "port = 1234$cluster" -C 'max_connections = 10' -C shared_buffers=1M;
>        >  done
> 
>      A possible future improvement would be to provide some basic
>      formatting corrections to allow specificications such as -C 'port
>      1234', -C port=1234, and -C 'port = 1234' to all be ultimately output
>      as 'port = 1234' in the final output.  This would be consistent with
>      postmaster's parsing.
> 
>      The -C flag was chosen to be a mnemonic for "config".
> 
> Regards,
> 
> David
> --
> David Christensen
> End Point Corporation
> david@endpoint.com
> 

-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>