Re: Clarify "allow_system_table_mods"

On Mon, Apr 25, 2016 at 8:41 PM, Adrian Klaver <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) 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?
>
> 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.
>
>
>
>> I'm afraid I'm done with this particular discussion. Hopefully it's
>> purpose is now clear and you understand a bit better what is required to
>> actually add a column to pg_class.
>>
>> Thanks!
>>
>> Stephen
>>
>>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

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!

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.