Tom Lane wrote:
> 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.
Late reply, but we are basically ignoring 'local' lines if the build
doesn't support unix domain sockets (windows), but throwing an error for
hostssl usage if ssl is not compiled in. Is the only logic here that
'local' is part of the default pg_hba.conf and hostssl is not? Is that
good logic?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
