Re: Providing catalog view to pg_hba.conf file - Patch submission

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Date: 2015-02-27 21:26:31
Message-ID: 12545.1425072391@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-02-27 22:00:44 Re: Providing catalog view to pg_hba.conf file - Patch submission
Previous Message Pavel Stehule 2015-02-27 21:14:00 Re: plpgsql versus domains