Re: Providing catalog view to pg_hba.conf file - Patch submission - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Providing catalog view to pg_hba.conf file - Patch submission
Date
Msg-id 12545.1425072391@sss.pgh.pa.us
Whole thread Raw
In response to Re: Providing catalog view to pg_hba.conf file - Patch submission  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Providing catalog view to pg_hba.conf file - Patch submission  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Providing catalog view to pg_hba.conf file - Patch submission  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql versus domains
Next
From: Pavel Stehule
Date:
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission