Re: Poor buildfarm coverage of strong-random alternatives

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

In response to

Responses

Browse pgsql-hackers by date

  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