On Thu, Jul 7, 2016 at 7:51 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> > I'm not sure how common a build without openssl is in the real world >> > though. >> > RPMs, DEBs, Windows installers etc all build with OpenSSL. But we probably >> > don't want to make it mandatory, no... >> >> I don't think that it is this much common to have an enterprise-class >> build of Postgres without SSL, but each company has always its own >> reasons, so things could exist. > > I agree that it's useful to have the support if PG isn't built with > OpenSSL for some reason.
OK, I am doing that at the end. And also while moving on... On another topic, here are some ideas to extend CREATE/ALTER ROLE to support SCRAM password directly: 1) protocol PASSWORD value, where protocol is { MD5 | PLAIN | SCRAM }, giving: CREATE ROLE foorole SCRAM PASSWORD value; 2) PASSWORD (protocol) value. 3) Just add SCRAM PASSWORD My mind is thinking about 1) as being the cleanest solution as this does not touch the defaults, which may change a couple of releases later. Other opinions? Note that I am also switching password_encryption to an enum, able to use as values on, off, md5, plain, scram. Of course, on => md5, off => plain to preserve the default. Other things that I am making conservative: - ENCRYPTED PASSWORD still implies MD5-encrypted password - UNENCRYPTED PASSWORD still implies plain text password - PASSWORD used alone depends on the value of password_encryption So it would be possible to move to scram by default by setting password_encryption to 'scram'. Objections are welcome, I am moving into something respecting the default behavior as much as possible. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers