On Fri, Sep 15, 2017 at 1:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Sep 14, 2017 at 10:21 AM, Alvaro Herrera
> <alvherre@alvh.no-ip.org> wrote:
>> BTW I added --with-ldap and --with-pam to the configure line for the
>> reports in coverage.postgresql.org and the % covered in auth.c went from
>> 24% to 18.9% (from very bad to terribly sad).
>
> Improved code coverage is becoming a fad.
I don't think that this is necessarily bad for authentication. I mean,
you write something and make sure that it actually works, but you also
make sure that the code you have is *compatible* with libraries the
code is linking to. The second part is important to me. For example
with the SSL tests we can know if there is a breakage, and if this
involves our code of OpenSSL's say after a version upgrade.
Now I think as well that it is not completely the role of this patch
to provide more test coverage for LDAP now because infrastructure
lacks. One requirement that is showing up as a remark from Peter E
(from the pg_receivewal --endpos thread
https://www.postgresql.org/message-id/49b529c1-0f44-d905-b33c-005ec0114d09@2ndquadrant.com),
is that we should have a simple perl module allowing to find easily if
Postgres is compiled with a given dependency or not so as tests can
decide if they have to be skipped or run.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers