| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: scram and \password |
| Date: | 2017-04-26 17:01:50 |
| Message-ID: | CA+TgmoaZTPgtt8s_FOqV8ZXCgpiZ_8AjXXUS5Y5hxO_vLkrL7A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 26, 2017 at 12:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2017-04-26 17:03:00 | RFC: ALTER SYSTEM [...] COMMENT |
| Previous Message | Simon Riggs | 2017-04-26 17:01:28 | Re: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly |