I wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Sat, Aug 27, 2011 at 01:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Now, seeing as how NEGOTIATE_SSL_CODE has been understood by every build
>>> since PG 7.0, I believe that this is dead code and we could remove it;
>>> it seems exceedingly unlikely that any modern build of libpq will ever
>>> be used to talk to a server that responds to that with "E".
>> What will be the result if you do use the modern libpq against that?
> I'll check it after I write the patch, but what I'd expect to happen is
> that libpq would fail the connection and report the server's error
> message, which would be something like "unrecognized protocol version
> number". Anybody who did complain of this could be told to use
> sslmode=disable when talking to the ancient server.
Just for the archives' sake, what happens with the committed patch is
either a successful non-SSL connection:
$ psql "dbname=template1 sslmode=prefer host=localhost"
NOTICE: Unrecognized variable client_encoding
psql (9.2devel, server 6.5.3)
WARNING: psql version 9.2, server version 6.5. Some psql features might not work.
Type "help" for help.
or if you tried to force SSL usage, you get this:
$ psql "dbname=template1 sslmode=require host=localhost"
psql: Unsupported frontend protocol.
Unsupported frontend protocol.$
The reason for the repeated message is that libpq tries twice and
appends the error messages to its buffer both times. I didn't think
this was important enough to try to fix; and anyway I seem to recall
that it's intentional that we append the messages from multiple
connection attempts.
BTW, this response starting with "U", together with the buffer flush bug,
seems to explain some of the old reports in the archives, such as
http://archives.postgresql.org/pgsql-hackers/2005-09/msg01106.php
regards, tom lane