Re: Clarify "allow_system_table_mods"

On Monday, April 25, 2016, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:

>
>
> On Mon, Apr 25, 2016 at 8:41 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <javascript:_e(%7B%7D,'cvml','adrian(dot)klaver(at)aklaver(dot)com');>> wrote:
>
>> On 04/25/2016 05:29 PM, Stephen Frost wrote:
>>
>>> * Melvin Davidson (melvin6925(at)gmail(dot)com
>>> <javascript:_e(%7B%7D,'cvml','melvin6925(at)gmail(dot)com');>) wrote:
>>>
>>>> Hmmm, if you go back a few comments, you will note that per initdb
>>>> --help
>>>> there is no such option available.
>>>>
>>>
>>> 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?
>
>
>>
I suspect it means that when initdb starts up the database (in single user
mode is suspect) it sets that option and does its thing. And since its
thing involves making the catalogs look like whatever the C structure are
expecting there isn't an issue.

> I am completely in agreement with what Adrian said.
> I only started this conversation because my enhancement request to add
> relcreated to pg_class seemingly was going nowhere. I was told if I wanted
> to do that, I should write the patch myself
> and submit it, but I am not a developer, so that option is out.
>
>
>
> I also pointed to a "Customer Feedback" url that has apparently been
> active for quite awhile, but the developers deny knowledge of that.
>
> So if we are going to use this list as a medium for enhancement requests,
> I feel it is only fair that
> 1. A formal committee to review all such requests be created.
> 2. That committee should meet (or review) periodically all enhancement
> requests.
> 3. If an enhancement request is approved, then the list should be updated
> with it, or else
> if rejected, then a reason (such as dangerous code or negative
> performance) should be stated.
> 4. Using, "it won't work in all cases" is not a reason for rejection.
> Think of positive benefits!
>
>

I guess "life isn't fair" is the most appropriate response to that...

I don't dispute that these things would be nice but one doesn't get to use
software for free and then bitch about the
disparate organizational practices of the people writing the code. And I
wouldn't classify the above list of self-proclaimed community entitlements
as being particularly helpful - especially buried on an unrelated thread
regarding a guc.

You've found a piece of obscure documentation that is unclear. You've been
told how things work. Feel free to either submit a re-wording or an actual
patch to prevent the next person from having the same confusion - depending
on how motivitated you are toward that prevention. Then, I'd suggest
simple acceptance and moving on.

David J.