Guillaume Lelarge <guillaume@lelarge.info> writes:
> Le 28/12/2010 16:34, Tom Lane a �crit :
>> I'm still wondering what's the actual use-case for exposing this inside
>> SQL. Those with a legitimate need-to-know can look at the slave
>> server's config files, no?
> This is something I wanted to have in 9.0 when I coded in pgAdmin some
> features related to the HotStandby. Knowing on which IP is the master
> can help pgAdmin offer the user to register the master node.
> It's also interesting to get lag between master and slave. As soon as
> I'm connected to a slave, I can connect to the master and get the lag
> between them. Something I can't do right now in pgAdmin.
The proposed primary_conninfo seems like a pretty awful solution to
those problems, though.
1. It'll have to be restricted to superusers, therefore ordinary
users on the slave can't actually make use of it.
2. It's not what you want, since you don't want to connect as the
replication user. Therefore, you'd have to start by parsing out
the parts you do need. Expecting every client to include conninfo
parsing logic doesn't seem cool to me.
I can see the point of, say, a primary_host_address() function returning
inet, which would be way better on both those dimensions than the
current proposal. But I'm not sure what else would be needed.
regards, tom lane