RE: [HACKERS] RE: [INTERFACES] Re: SSL patch

Поиск
Список
Период
Сортировка
От Ansley, Michael
Тема RE: [HACKERS] RE: [INTERFACES] Re: SSL patch
Дата
Msg-id 1BF7C7482189D211B03F00805F8527F70ED084@S-NATH-EXCH2
обсуждение исходный текст
Ответы Re: [HACKERS] RE: [INTERFACES] Re: SSL patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Why does anything need to be broken if a different port is used?  Same way
as web browsers use 80 for clear http, and 443 (by default) for SSL.  But a
server cannot dish up http and https on the same port.  Then the whole
compatibility issue falls away.  Think of it as using 'pgsql' for clear
connections, and 'pgsqls' for SSL connections.  This way, a post-6.6 client
can still connecct to a pre-6.6 server, using 'pgsql', a pre-6.6 client can
connect to a post-6.6 server using 'pgsql', and a post-6.6 client can
connect to a post-6.6 server using 'pgsql', or 'pgsqls'.

Or is there an issue using different ports?

>> > Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> > >> But, we've had protocol changes before that breaks backward
>> > >> compatibility...why is this all of a sudden a problem?
>> > 
>> > > No reason to change the protocol when we don't need to.
>> 
>> What I meant is that there is reason to break compatibility when we
>> don't need to.  Magnus seems like he has addressed this already.
>> 
>> > 
>> > The point is that we *do not have to* break backwards compatibility to
>> > add this feature, and indeed hardly anything would be gained by
breaking
>> > compatibility.  See subsequent messages from myself and Magnus.
>> > 
>> >             regards, tom lane
>> > 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Adriaan Joubert
Дата:
Сообщение: Re: [HACKERS] Re: [SQL] inserts/updates problem under stressing !
Следующее
От: Dmitry Samersoff
Дата:
Сообщение: Re: [HACKERS] plperl intial pass