Thread: psql: Make SSL info display more compact
Currently, when you connect with psql over SSL, you get a display like this: psql (15devel) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) Type "help" for help. Since support for SSL compression has been removed from PostgreSQL, it doesn't seem sensible to display it anymore. And while we're there, I think the bits information is redundant, since it can be derived from the cipher suite, either because it's part of the name (as in the example) or by looking it up somewhere. So I propose that we make this display a bit more compact like this: psql (15devel) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384) Type "help" for help. See attached patch.
Attachment
> On 28 Feb 2022, at 10:02, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > Since support for SSL compression has been removed from PostgreSQL, it > doesn't seem sensible to display it anymore. This was originally done, but all client side changes reverted as there still are server versions in production which allow compression. -- Daniel Gustafsson https://vmware.com/
Daniel Gustafsson <daniel@yesql.se> writes: >> On 28 Feb 2022, at 10:02, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > >> Since support for SSL compression has been removed from PostgreSQL, it >> doesn't seem sensible to display it anymore. > > This was originally done, but all client side changes reverted as there still > are server versions in production which allow compression. How about making it show "compression: on" if compression is on, but nothing in the common "off" case? - ilmari
On Mon, Feb 28, 2022 at 10:50:01AM +0000, Dagfinn Ilmari Mannsåker wrote: > Daniel Gustafsson <daniel@yesql.se> writes: >> On 28 Feb 2022, at 10:02, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: >> This was originally done, but all client side changes reverted as there still >> are server versions in production which allow compression. > > How about making it show "compression: on" if compression is on, but > nothing in the common "off" case? Hm, no, as it can be useful to know that compression is disabled when connecting to an old server. What about that making the information shown version-aware? I would choose to show the compression part only for server versions where it is settable. -- Michael
Attachment
On 28.02.22 11:50, Dagfinn Ilmari Mannsåker wrote: > Daniel Gustafsson <daniel@yesql.se> writes: > >>> On 28 Feb 2022, at 10:02, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: >> >>> Since support for SSL compression has been removed from PostgreSQL, it >>> doesn't seem sensible to display it anymore. >> >> This was originally done, but all client side changes reverted as there still >> are server versions in production which allow compression. > > How about making it show "compression: on" if compression is on, but > nothing in the common "off" case? That would work for me.
On 28.02.22 12:21, Michael Paquier wrote: > What about that making the information > shown version-aware? I would choose to show the compression part only > for server versions where it is settable. That might lead to confusing results if you are not connecting to something that is a stock PostgreSQL server.
> On 28 Feb 2022, at 12:56, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > On 28.02.22 11:50, Dagfinn Ilmari Mannsåker wrote: >> Daniel Gustafsson <daniel@yesql.se> writes: >>> This was originally done, but all client side changes reverted as there still >>> are server versions in production which allow compression. >> How about making it show "compression: on" if compression is on, but >> nothing in the common "off" case? > > That would work for me. On POLA grounds I would prefer to never to show it. If we ever get libpq compression and want to show that, I'd prefer that we didn't end up "compression" meaning one thing except when it means two things. -- Daniel Gustafsson https://vmware.com/
Daniel Gustafsson <daniel@yesql.se> writes:
> On 28 Feb 2022, at 12:56, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>> On 28.02.22 11:50, Dagfinn Ilmari Mannsåker wrote:
>>> How about making it show "compression: on" if compression is on, but
>>> nothing in the common "off" case?
>> That would work for me.
> On POLA grounds I would prefer to never to show it. If we ever get libpq
> compression and want to show that, I'd prefer that we didn't end up
> "compression" meaning one thing except when it means two things.
Well, any such output would presumably be on a different line and
thus distinguishable from the SSL property; plus, it'd be impossible
for both forms to show up in the same connection.
However, how about writing "SSL compression: on" versus writing
nothing? That avoids doubt about what it means. I don't buy
Michael's argument that this is ambiguous, either.
regards, tom lane
On 28.02.22 16:12, Tom Lane wrote: > Daniel Gustafsson <daniel@yesql.se> writes: >> On 28 Feb 2022, at 12:56, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: >>> On 28.02.22 11:50, Dagfinn Ilmari Mannsåker wrote: >>>> How about making it show "compression: on" if compression is on, but >>>> nothing in the common "off" case? > >>> That would work for me. > >> On POLA grounds I would prefer to never to show it. If we ever get libpq >> compression and want to show that, I'd prefer that we didn't end up >> "compression" meaning one thing except when it means two things. > > Well, any such output would presumably be on a different line and > thus distinguishable from the SSL property; plus, it'd be impossible > for both forms to show up in the same connection. > > However, how about writing "SSL compression: on" versus writing > nothing? That avoids doubt about what it means. I don't buy > Michael's argument that this is ambiguous, either. I didn't mean to reopen the whole SSL compression can of worms here, I was mistaken about the level of support left after PG14. I was merely lightly annoyed that the psql startup display got quite long with not very interesting information. I propose a reduced patch that just removes the "bits" display, since that is redundant with the "cipher" display.
Attachment
> On 1 Mar 2022, at 09:44, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > I propose a reduced patch that just removes the "bits" display, since that is > redundant with the "cipher" No objections from me. -- Daniel Gustafsson https://vmware.com/