Re: Providing catalog view to pg_hba.conf file - Patch submission
От | Tom Lane |
---|---|
Тема | Re: Providing catalog view to pg_hba.conf file - Patch submission |
Дата | |
Msg-id | 12545.1425072391@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Providing catalog view to pg_hba.conf file - Patch submission (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Providing catalog view to pg_hba.conf file - Patch submission
Re: Providing catalog view to pg_hba.conf file - Patch submission |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > Right, we also need a view (or function, or both) which provides what > the *active* configuration of the running postmaster is. This is > exactly what I was proposing (or what I was intending to, at least) with > pg_hba_active, so, again, I think we're in agreement here. I think that's going to be a lot harder than you realize, and it will have undesirable security implications, in that whatever you do to expose the postmaster's internal state to backends will also make it visible to other onlookers; not to mention probably adding new failure modes. There are also nontrivial semantic differences in this area between Windows and other platforms (ie in an EXEC_BACKEND build the current file contents *are* the active version). If you insist on two views you will need to explain why/how they act differently on different platforms. I think the proposed mechanism (ie read and return the current contents of the file) is just fine, and we should stop there rather than engineering this to death. We've survived twenty years with *no* feature of this sort, how is it suddenly essential that we expose postmaster internal state? regards, tom lane
В списке pgsql-hackers по дате отправления: