Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
>> In the particular case at hand, if someone is trying to use the same
>> hostssl-containing pg_hba.conf across multiple systems, is it not
>> reasonable to suppose that he should have SSL turned on in
>> postgresql.conf on all those systems? If he doesn't, it's far more
>> likely to be a configuration mistake that he'd appreciate being pointed
>> out to him, instead of having to reverse-engineer why some of the
>> systems aren't working like others.
> I think, people use and configure PostgreSQL in all kinds of ways, so we
> shouldn't assume what they might be thinking. Especially if an
> artificial boundary has the single purpose of being "helpful".
Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both developers (who don't have to worry
about testing/fixing such code paths) and users (who won't have to deal
with the bizarre failure modes).
But in any case, I think that the presence of a hostssl line in
pg_hba.conf is pretty strong evidence that the admin intends to use SSL,
so we should tell him about it if he's forgotten the other piece of
setup he needs.
> If people want their configuration checked for "sanity" (by someone's
> definition), there might be logging or debugging options in order for
> that.
If anyone else agrees with your viewpoint, maybe we could compromise on
emitting a LOG message indicating that the hostssl line will be ignored
due to SSL being turned off. But I think your approach penalizes people
who make simple mistakes in order to lend marginal support to an
entirely-hypothetical advanced use case.
regards, tom lane