Re: [HACKERS] scram and \password - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] scram and \password
Date
Msg-id CA+TgmoaZTPgtt8s_FOqV8ZXCgpiZ_8AjXXUS5Y5hxO_vLkrL7A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 26, 2017 at 12:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Would it be worth making password_encryption be GUC_REPORT so that
> it could be guaranteed available, without a server transaction,
> from any valid connection?  I'm generally resistant to adding
> GUC_REPORT flags, but maybe this is a time for an exception.

Well, as Heikki just wrote a few messages upthread:

---
As an alternative, I considered making password_encryption GUC_REPORT,
so that libpq would always know it without having to issue a query.
But it feels wrong to send that option to the client on every
connection, when it's only needed in the rare case that you use
PQencryptPasswordConn(). And if we added new settings like the
iteration count in the future, those would need to be GUC_REPORT too.
---

I think those are both good points.

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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Next
From: "Joshua D. Drake"
Date:
Subject: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT