| 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: | Whole Thread | Raw Message | 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 |