> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
>> On Mon, 12 Apr 2004, Bruce Momjian wrote:
>>> I think the major problem with your -C & -D idea is that you require
>>> the
>>> administrator to link the config file and data directory everytime you
>>> start the db, and that might be error-prone.
>
>> Well, AFAICS the patch doesn't require that actually, it merely allows
>> the
>> separation.
>
> Well, it doesn't *require* it, but if you actually *use* the patch in
> the proposed way then you end up with the error-prone need to specify
> the correct combination of -C and -D on the command line. I think what
> people are questioning is whether we can't find a variant solution that
> avoids that risk.
This is completely wrong with regards to the patch. The patch "allows"
"-D" on the command line, just like you can override the socket port,
number of buffers, and other options, but the intention is that you do NOT
use the "-D" option.
>
> The bottom line to me is that config versus data ought to be a one-to-
> many relationship, at least if you accept the premise that shared config
> is reasonable at all. Putting a datadir spec inside the config file
> makes it impossible to share config files across datadirs, and so that
> seems to conflict with the argument (which is being made in support of
> this very same patch) that sharable config is good. On the other hand,
> if you make data point to config then you have a very natural way to
> manage the one-to-many relationship.
>
> Separate -C and -D would make sense if it were a many-to-many
> relationship (ie, you could sensibly use many different configs with the
> same data dir), but the case for multiple configs with one data dir
> seems pretty weak to me, and outweighed by the risk factors.
I hear "risk" but what risk?