On Fri, Sep 15, 2017 at 1:38 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Sep 14, 2017 at 10:21 AM, Alvaro Herrera > <alvhe...@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-005ec0114...@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
