From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, cary huang <hcary328(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: Setting min/max TLS protocol in clientside libpq |
Date: | 2020-01-07 00:51:08 |
Message-ID: | 20200107005108.GC2386@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 06, 2020 at 09:37:54AM -0500, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Not having thought about it in much detail, but it's a fairly common
>> scenario to have a much newer version of libpq (and the platform it's
>> built on) than the server. E.g. a v12 libpq against a v9.6 postgres
>> server is very common. For example, debian based systems will
>> auto-upgrade your libpq, but not your server (for obvious reasons).
>> And it's also quite common to upgrade platforms for the application
>> much more frequently than the database server platform.
>
> Yeah, there's a reason why we expect pg_dump and psql to function with
> ancient server versions. We shouldn't break this scenario with
> careless rejiggering of libpq's connection defaults.
Good points. Let's not do that then.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-01-07 01:37:43 | Re: RFC: seccomp-bpf support |
Previous Message | Michael Paquier | 2020-01-07 00:22:16 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |