From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Poor buildfarm coverage of strong-random alternatives |
Date: | 2018-12-28 15:16:07 |
Message-ID: | 21150.1546010167@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> Yeah, there probably isn't anyone needing --disable-strong-random in
> practice. The situation is slightly different between the frontend and
> backend, though. It's more likely that someone might need to build libpq
> on a very ancient system, but not the server. And libpq only needs
> pg_strong_random() for SCRAM support. It'd be kind of nice to still be
> able to build libpq without pg_strong_random(), with SCRAM disabled. But
> that's awkward to arrange with autoconf, there is no "--libpq-only"
> flag. Perhaps replace the backend !HAVE_STRONG_RANDOM code with #error.
> +1 for just ripping it out, nevertheless. If someone needs libpq on an
> ancient system, they can build an older version of libpq as a last resort.
The other workaround that remains available is to build --with-openssl.
So the arguments for keeping !HAVE_STRONG_RANDOM seem pretty weak from
here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2018-12-28 15:46:10 | Re: pg_dump multi VALUES INSERT |
Previous Message | Surafel Temesgen | 2018-12-28 14:57:23 | Re: pg_dump multi VALUES INSERT |