Re: Clarify "allow_system_table_mods"

Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 04/25/2016 05:29 PM, Stephen Frost wrote:
>> It's not an option *to* initdb, it's an option which is used *by*
>> initdb.

> That really did not clear things up:) Does it mean that you can
> pre-populate the $DATA directory with a postgresql.conf that has
> allow_system_table_mods set to on and initdb will pick it up?

No, initdb will complain if you point it at a nonempty directory...

The way that initdb uses this option is to pass it as a command-line
switch to the standalone backend it invokes.

> Personally, I think tampering with the system catalogs is foolish. Still
> if you have documentation for something(even if it is a foot gun) it
> should be understandable. If the intent is for end users/dba's not use
> these options I would say take then out of the user docs and put them in
> the developer Wiki section.

It's already in a section titled "Developer Options", with the heading

The following parameters are intended for work on the PostgreSQL
source code, and in some cases to assist with recovery of severely
damaged databases. There should be no reason to use them on a
production database.

I'm not sure what else we should do, short of writing "HERE BE DRAGONS"
set in blackletter type.

(Having said that, we could change "This is used by initdb." to "This
is meant only for use by initdb". But I don't know that that really
would discourage anybody.)

regards, tom lane