From: | Seth Robertson <in-pgsql-hackers(at)baka(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Automatic client certificate selection support for libpq v1 |
Date: | 2009-05-08 21:52:12 |
Message-ID: | 200905082152.n48LqCkN007954@no.baka.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
In message <14727(dot)1241816192(at)sss(dot)pgh(dot)pa(dot)us>, Tom Lane writes:
> It is of course possible to support both at the same time (at
> compile-time, if nowhere else).
Yes, I suppose we'd not wish to just drop openssl completely.
I wonder how much code duplication would ensue from a compile-time
choice of which library to use ...
My only datapoint for you is curl, which is an application I happen to
have discovered that can use either NSS and OpenSSL.
Lines Words Chars Filename
2508 7890 74682 ssluse.c
1331 3708 36411 nss.c
I imagine that you would more or less have to provide a different
be-secure.c and fe-secure.c file for the two different
libraries--whether as a separate file or via #ifdefs. It looks like
there is a small amount of common code present (why *is*
pg_block_sigpipe() in that file anyway?)
-Seth Robertson
in-pgsql-hackers(at)baka(dot)org
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-05-08 21:55:42 | Re: Some 8.4 changes needed according to pg_migrator testing |
Previous Message | Tom Lane | 2009-05-08 21:50:28 | Re: strict version of version_stamp.pl |