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/9837222c0910240641p7d75e2a4u2cfa6c1b5e603...@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 generated postgresql.conf file for use > in programmatic generation. In my case, I'd been creating multiple db > clusters with a script and would have specific overrides that I needed to > make. This patch fell out of the desire to make this a little 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 > da...@endpoint.com > -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
