From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> |
Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] RE: [INTERFACES] Re: SSL patch |
Date: | 1999-07-26 13:58:59 |
Message-ID: | 20663.932997539@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
> Why does anything need to be broken if a different port is used?
That was the quick-and-dirty answer that I suggested to begin with, but
Magnus objected on the grounds that it would be a nontransparent change
for *users* of Postgres; anyplace that knows what port it is supposed
to connect to would have a problem. I think he has a good point.
Pushing the conversion headaches out of our bailiwick does not mean that
there are no conversion headaches.
The solution that we arrived at does not break compatibility nor require
an additional port --- it will just mean a slightly slower connection
process when an SSL-using client tries to connect to a non-SSL-capable
server. I think that's OK, since that scenario is probably the least
common of the four possible combinations. (And if you're really worried
about a few extra millisec of startup time, the client-side library will
accept a connect option that tells it not to try the SSL connection...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Hollomon | 1999-07-26 13:59:54 | Re: [HACKERS] plperl intial pass |
Previous Message | Oleg Bartunov | 1999-07-26 13:56:36 | Re: [HACKERS] postgres Web problem |