Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers