| From: | Andrew Chernow <ac(at)esilo(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PQinitSSL broken in some use casesf |
| Date: | 2009-03-29 03:24:56 |
| Message-ID: | 49CEEA08.10102@esilo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas wrote:
>
> Is there more substance here than meets the eye?
>
No, you about summed it up. We need a way to init libssl and libcrypto
in any combo. Along the way, PQinit() was discussed which may have
muddied the waters.
I prefer leaving the PQinitSSL function alone, thus my patch that
implements PQinitSecure(flags).
Adding PQinitSSL(new_value) seem reasonable to me. My only complaint
has been that the API user has no way of knowing if the function
understood their request. An older libpq would treat any non-zero
argument as one, which would silently fail/mis-behave from a new apps
perspective. Not sure this can be solved.
In the end, anyway you do it will have an issue or two. I agree that it
really doesn't matter, all methods would probably do the trick.
Andrew Chernow
eSilo, LLC
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-03-29 04:03:45 | Re: PQinitSSL broken in some use casesf |
| Previous Message | Robert Haas | 2009-03-29 02:38:20 | Re: psql \d* and system objects |