Re: Merging postgresql.conf and postgresql.auto.conf
От | Robert Haas |
---|---|
Тема | Re: Merging postgresql.conf and postgresql.auto.conf |
Дата | |
Msg-id | CA+TgmoYdrBOEVUnT1xPhe2ZR+rXw-DZbkT+x8cg8sc-TBLiHsw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Merging postgresql.conf and postgresql.auto.conf (David Johnston <david.g.johnston@gmail.com>) |
Ответы |
Re: Merging postgresql.conf and postgresql.auto.conf
|
Список | pgsql-hackers |
On Tue, Jan 20, 2015 at 4:07 PM, David Johnston <david.g.johnston@gmail.com> wrote: > sourceline and sourcefile pertain only to the current value while the point > of adding these other pieces is to provide a snapshot of all the different > mappings that the system knows about; instead of having to tell a user to go > look in two different files (and associated includes) and a database catalog > to find out what possible values are in place. That doesn't solve the need > to scan the catalog to see other possible values - though you could at least > put a counter in pg_settings that indicates how many pg_db_role_setting > entries reference the given variable so that if non-zero the user is clued > into the fact that they need to check out said catalog table. This last proposal seems pointless to me. If the user knows about pg_db_role_setting, they will know to check it; if they don't, a counter won't fix that. I can see that there might be some utility to a query that would tell you, for a given setting, all sources of that setting the system knew about, whether in configuration files, pg_db_role_setting, or the current session. But I don't see that putting information that's already available via one system catalog query into a different system catalog query helps anything - we should presume DBAs know how to write SQL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: