Re: pg_primary_conninfo

On Tue, Dec 28, 2010 at 17:43, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
> Le 28/12/2010 17:36, Tom Lane a écrit :
>> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
>>> Le 28/12/2010 16:34, Tom Lane a écrit :
>> 1. It'll have to be restricted to superusers, therefore ordinary
>> users on the slave can't actually make use of it.
>>
>
> pgAdmin's users usually connect as superusers.

It would be a function for DBAs, of course. I don't see why "normal
users" would be intersted in it, really.

>> 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.
>>
>
> Yeah, it would be better that way. I'm actually interested in Magnus's
> patch because, during 9.0 development phase, I had in mind to parse the
> primary_conninfo till I found I could not get this value with SHOW or
> current_setting().
>
> But, actually, what I really need is host and port. This way, I could
> connect to the master node, with the same user and password that was
> used on the slave node.

I agree it might well be more useful to have it split up for us. We'd
need the host name (though it would have to be text and not inet,
since we'd need the unix socket path for a local connection) and port.
And username. But certainly not password, and probably none of the
other parameters.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/