Re: Clarify "allow_system_table_mods"

Поиск
Список
Период
Сортировка
От Melvin Davidson
Тема Re: Clarify "allow_system_table_mods"
Дата
Msg-id CANu8FiyZ8JRvoh+6R8CZTiwW4D0daUxESS9NTdMrXz7tpz7gmw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Clarify "allow_system_table_mods"  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: Clarify "allow_system_table_mods"  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general


On Mon, Apr 25, 2016 at 8:41 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 04/25/2016 05:29 PM, Stephen Frost wrote:
* Melvin Davidson (melvin6925@gmail.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.klaver@aklaver.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.

В списке pgsql-general по дате отправления:

Предыдущее
От: George Neuner
Дата:
Сообщение: Re: Columnar store as default for PostgreSQL 10?
Следующее
От: Adam Brusselback
Дата:
Сообщение: Re: Columnar store as default for PostgreSQL 10?