Re: [HACKERS] scram and \password

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] scram and \password
Дата
Msg-id CA+TgmoaZTPgtt8s_FOqV8ZXCgpiZ_8AjXXUS5Y5hxO_vLkrL7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] scram and \password  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: [HACKERS] RFC: ALTER SYSTEM [...] COMMENT