Mark Woodward wrote:
Well, if you want PostgreSQL to act a specific way, then you are going
to
have to set up the defaults somehow, right?
Of course, which is why we could use a global table for most of it.
What if you wish to start the same database cluster with different settings?
Then change the setting and restart?
Which is cleaner? Using a configuration file which is going to be there
anyway, or trying to rig-up some sort of autostart.sql mechanism to put
PostgreSQL into its desired state?
Initdb could easily create this as part of the catalog/cluster.
Assuming you know the tuning parameters at creation time, hint: you don't.
Which isn't any different than now. You don't have a postgresql.conf
until you initdb, well you do but most people don't know about it.
You can do that easily if you have multiple catalogs which is what we do
when we want that.
I *really* dislike this sort of strategy.
It works great for us :) but each person has their own needs.
I also want an include directve that allows production or debugging
settings to be easily used.
Such as?
Printing out statement execution, timing, etc. obviously.
Well this can be done easily as having a debug conf and a prod conf.
Copy one over the other and HUP when required....
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
