Re: Proposal: knowing detail of config files via SQL

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Proposal: knowing detail of config files via SQL
Дата
Msg-id CAA4eK1JrLkMiLtOZ=Yry4gd7P-dHr4RQFqNosLQGJ-qMrC-G+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: knowing detail of config files via SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jan 23, 2015 at 3:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I know what the proposal is.  What I am questioning is the use-case that
> justifies having us build and support all this extra mechanism.  How often
> does anyone need to know what the "next down" variable value would be?

I would say not that often as I think nobody changes the settings in
configuration files every now and then, but it could still be meaningful
in situations as described upthread by Sawada.

I think similar to this, pg_reload_conf() or many such things will be used
not that frequently, it seems to me that here important point to consider
is that whether such a view could serve any purpose for real users?

If we see multiple value for same config parameter was possible even
previous to Alter System and there doesn't seem to be much need/demand
for such a view and the reason could be that user has no way of changing
the setting at file level with command, but now as we provide a way it
could be useful in certain cases when user want to retain previous
values (value in postgresql.conf).

I understand that usage of such a view is not that high, but it could be
meaningful in some cases.

> And if they do need to know whether a variable is set in postgresql.conf,
> how often wouldn't they just resort to "grep" instead?
>

Do always user/dba (having superuser privilege) access to postgresql.conf
file?   It seems to me even if they have access, getting the information via
SQL would be more appealing.

> (Among other
> points, grep would succeed at noticing commented-out entries, which this
> mechanism would not.)

> GUC has existed in more or less its current state for about 15 years,
> and I don't recall a lot of complaints that would be solved by this.
> Furthermore, given that ALTER SYSTEM was sold to us as more or less
> obsoleting manual editing of postgresql.conf, I rather doubt that it's
> changed the basis of discussion all that much.
>

By providing such a view I don't mean to recommend the user to change
the settings by editing postgresql.conf manually and then use Alter System
for other cases, rather it could be used for some cases like for default values
or if in rare cases user has changed the parameters manually.  


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: pg_upgrade and rsync
Следующее
От: David Rowley
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)