On 28/12/2018 01:14, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Thu, Dec 27, 2018 at 03:56:52PM -0500, Tom Lane wrote:
>>> More urgently, what about the lack of --disable-strong-random
>>> coverage? I feel like we should either have a buildfarm
>>> critter or two testing that code, or decide that it's no longer
>>> interesting and rip it out. backend_random.c, to name just
>>> one place, has a complex enough !HAVE_STRONG_RANDOM code path
>>> that I don't feel comfortable letting it go totally untested.
>
>> If that proves to not be useful, just dropping the switch sounds like
>> a good option to me. I would be curious to hear Heikki on the matter
>> as he has introduced the switch in the v10 time-frame.
>
> I might be misremembering, but I think it was me that pressed to have
> that switch in the first place :-). The reason my feelings have changed
> on the matter is mainly that we recently moved the compiler goalposts
> to C99. That reduces to about nil the chances of people being able to
> build PG on pre-turn-of-the-century platforms, at least without a lot
> of add-on software. So the idea that we should be able to cope with
> platforms lacking /dev/urandom has correspondingly dropped in value.
> Judging by our buildfarm sample, nothing released in this century
> lacks /dev/urandom.
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.
- Heikki