| 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: | Whole Thread | Raw Message | 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 |