On Tue, Mar 14, 2017 at 12:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: > If some other practice becomes better in v12, then we teach it about that > one. It's not like psql hasn't got many other server-version-dependent > behaviors.
Okay. Looking at the code, scram_build_verifier is only available on the backend side, so if we need to rethink it a bit to be able to have libpq build a SCRAM verifier: - The allocation of the verifier buffer needs to happen outside it, and the caller needs to provide an allocated buffer. Its size had better be calculated a macro. - The routine needs to be moved to scram-common.c. - a copy of hex_encode, say pg_hex_encode added in its own file in src/common/, needs to be provided. That's 6 lines of code, we could just have that in scram-common.c. Does that sound correct? > Alternatively, if what you mean by that is you don't trust SCRAM at all, > maybe we'd better revert the feature as not being ready for prime time. FWIW, I am confident about the code. Based on years watching this mailing list, switching long-term behaviors is usually done in a less faster pace, that's the only reason on which my opinion is based. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
