On Tue, Feb 14, 2017 at 11:36 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
>> <michael.paqu...@gmail.com> wrote:
>>> In short, I'd like to think that we should just filter out those two
>>> parameters by name and call it a day. Or introduce an idea of value
>>> set for the environment by adding some kind of tracking flag in
>>> PQconninfoOption? Though I am not sure that it is worth complicating
>>> libpq to just generate recovery.conf in pg_basebackup.
>>
>> Yeah, I'm not sure what the best solution is.  I just thought it was strange.
>
> Thinking more about this, perhaps the correct answer is to do nothing?
> target_session_attrs being set is rather similar to sslmode or
> sslcompression for example. They are here but don't hurt. The same
> thing applies to passfile: if the file is not here the client would
> still ask for input. If it is here, things are helped a bit.

Let's wait and see if anybody else has an opinion.  I imagine that, as
further libpq parameters are added, eventually this is going to get
long and annoying enough that we want to do something about it.  But
we might not have reached that point just yet.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to