Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfoU5-002Su8-KW for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Feb 2024 22:02:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rfoU3-008xRi-Pp for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Feb 2024 22:02:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfoU3-008xRa-F7 for pgsql-hackers@lists.postgresql.org; Thu, 29 Feb 2024 22:02:31 +0000 Received: from mail-cpzbra01olkn2041.outbound.protection.outlook.com ([40.92.97.41] helo=BRA01-CPZ-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfoTz-0029Zf-VO for pgsql-hackers@postgresql.org; Thu, 29 Feb 2024 22:02:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ergVdiv5lNY97heXmwfcDgPniVG3JF+GJHJ4OLyWSjq0fw7Z8evU6870TZhDb9QZ1pblx3sSwYRCazwhc3MtbejxCZDtVniVqqGfWzsAjECa6KvTqi5W4bry8+Lvk1hZ3wE2nAuUL+o6ipZyETtsvn3duNwTnRQxTxati7aRNWeQSfz0AAZ4z1qrDcP4ZkIo/2HDNA/mA3xDCCHnOjkHFjQ00vHNmkPRHY4fcGvkP02oUdDMdIdWqzp/dv43wsVoFplN1Cy447oBh+XOswtKS/W/A/4DvoBxj3bTq8pn+k57BQ50h/ySuHeUvsFRGO25Ez8GnbB6fRBHU6vnbDag+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W/8nW2JSnPOAlLnsAt7/D+rqy6nYuyYjLeFyalNZ+zo=; b=el+eF7a29OvdPwG8fnSboYo5vfrLKVWgRP2tJJl04tUXTAEVKd2iwCJr1iq40iioDzUx2BNWlv5bFJ3kEM1ysjhonWiVrFOMV0CIcbAYoYmsdDZk+Ko1HhiV38DBAWExeEy8HuP9DVXBQI7jlhTq3atndMUk8asSK8iZLOl/l0H6qNvYRI+Orepk1i/bfG7BICMAgYeCbUDHgoJrlpON4y+8k4B/Z8WVm63Q+6HK9SVJkedFXUk9aw6/5E0bOsSZmVz0tajbWzd9bFzIjvzzCcTNiVeBr87VFa8GrmgkOE8/MqbdZEi3+Rq0q1zkCJDJZGGe+qzPiTe3h+2n8poCNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:2dc::11) by CP4P284MB1586.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:e7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.41; Thu, 29 Feb 2024 22:02:21 +0000 Received: from CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM ([fe80::ce6:bf75:3d4a:97cf]) by CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM ([fe80::ce6:bf75:3d4a:97cf%2]) with mapi id 15.20.7316.039; Thu, 29 Feb 2024 22:02:21 +0000 From: Maiquel Grassi To: Nathan Bossart CC: Jim Jones , Pavel Luzanov , Erik Wienhold , "pgsql-hackers@postgresql.org" Subject: RE: Psql meta-command conninfo+ Thread-Topic: Psql meta-command conninfo+ Thread-Index: AQHaWRQuU7L2MD2CX0quiO/hLxQK8bD9n9eAgAAOagCAABlrgoAABsOAgAABrYCAAAkRMoAAAaIAgABfmwKAAJe3AIAAHVoLgAAnEwCAADA+O4ABA4CAgAA4UGOAASa0gIAFGF5sgAMAW4CAAhkLZoAAKvw7gADbloCAAE0igIABWfsIgAuJhgCAB/CkKA== Date: Thu, 29 Feb 2024 22:02:21 +0000 Message-ID: References: <49edac91-d47f-4cac-ae12-d51cabbd87c9@postgrespro.ru> <49635a5b-3d32-4f05-8ce4-c55c70181888@uni-muenster.de> <8a93f6c0-795f-4260-a5fd-07ccbddbc88f@uni-muenster.de> <20240216155449.GA1236054@nathanxps13> <20240224204412.GA1866465@nathanxps13> In-Reply-To: <20240224204412.GA1866465@nathanxps13> Accept-Language: pt-BR, en-US Content-Language: pt-BR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [SzKCZ5dxbq+vQv8oq/0l81JZBPW89abuGgbSAuW7At7vDsTJa70qlPmBSObEsXff] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CP8P284MB2496:EE_|CP4P284MB1586:EE_ x-ms-office365-filtering-correlation-id: 88c58c36-c078-44a4-3ddb-08dc39721ab0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rahrW/ygX6b2Qr5fJX+OIKi2i/PG7DN1WRhyWTedJWNqFggczadsb/oIuDm0hty4qztLFKkPe4TMZJSKwsWbzzYF+vXgcELbzafJAYp41ZqM6V2Tk6JzDP/1jDP0BdZRBkPnfHDuPXh9ipp22IapxJM+YlD23DaaeP7XTmnY1QyKmRat5HBSVQsXyZcVTGynpCZ11qlKBn3Jsa8xNJT0vAZH5UPfmEO8rB5YSQ6erzT5hkxJBn4xbSOVSp1phlzcAYYYwYOHT22RkNY0Kbu9VyEXhxayUdQGdUlq7TLDE4ei0a0fljt6P+HBbsT880j2lTZVT4MZj9RygLZyfv6MqqW1OGNd0FCCo9+IVAjYjXe8iMBByLKQabppXr8yUotukTsKwoAnuTwC3JiINpGWiEDxu3CywfPCoX14nZPLQ1Aq0Krqt+kFc1+CuUN1VlUzDkKchJJTG8rdBW+++LLRabvqO8EiVgoyTw5a2fa14Ah+r8lpCjxwnnqClsXzQWpDLVvphCwtkl0mjkIPtOyGuqb9g2tpavjayCoY2IBUdIxU/dNIZjzANvlGSvW/DCGIKzN5QnnzJCUUxDQ9ucwdR9pJRVK0SB6okZC43FX51AhYoMSx3kM2mU9CVr1VMwGcNcP2DuuSWuyzswHC7j8ilGt8uAPfomM+FhAKWCdy8Cg= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?f1xkvv4O5qQ4Pz21Te+wtjkxdpwL9oBDuKsr4157HDjGBpvHJutH8k3xe4?= =?iso-8859-1?Q?5iMNoK6UzxsMxJqFG+LicntgC7lySXo8CqxhvP5sgE4PVqFDOO0WgK+RtS?= =?iso-8859-1?Q?/ruM2JVnMjCpJTzkGgYmDsamCu/3kZYtigW01yc6+HGGYDhVUXVhH0svG8?= =?iso-8859-1?Q?PIpjqsz0rAZQKChyYsPinAq0MLiFjAVG5tyjRu2tk7Lc2CGoMXyISyf8aQ?= =?iso-8859-1?Q?fYdKdEMkN7LI6FtsZ23s3zqmERHvssdZuzBz5M72xIXH7FjkHriwbadrRM?= =?iso-8859-1?Q?KXmgRVrt+e4+wedOOQkC7p/567uyRoVuhA8+kigR+xkjEDjqi1W5h/YSak?= =?iso-8859-1?Q?XZqOfJnGTThMLVmlt7CmP86xl5Oji+7aDWXHxrNLmfmXRgC/BewrZaAbFu?= =?iso-8859-1?Q?Hrj2yEiHuM2iOG8bY8YYqdf16mpLhjwM3gCv6OU1SHZKHNyyD8XoPWkB3o?= =?iso-8859-1?Q?v0wpbhI0ImsyiYAjdUF7mKdffuhk3lu7WrggMWDMPDFGcy1gUkxclc7vs2?= =?iso-8859-1?Q?yB6a/xjDub4B41eFIyC4TGBpF9JwJ/UPtp1ezLXpIuyArM+TrMtCaZFG2c?= =?iso-8859-1?Q?PrCLnRyz8a2sTcmi2UPMMC6o6X8dP1lG7Bn7TPVatgtKuzgKYfTVZGKiRX?= =?iso-8859-1?Q?PGSQEqSZENRwAVNiQOWhLndBZtK/M2HnUSXdCou0gdJt0mt4j809WqaCna?= =?iso-8859-1?Q?dof9Px3IGebKnjJ3zCVwZm+KjPqmHxEqxTiPTST/8LTBELrUlBz+XMM52B?= =?iso-8859-1?Q?bmkEFza17ZhQVHMxeYkvShdnNXwU8NqDIfcaknaR137FPFI02UFFcbw0TB?= =?iso-8859-1?Q?d9u1NWxm7309rpZXlcP1c9mhfBegC10HNoOatkKPOsIyBsUJVOfISUOAXa?= =?iso-8859-1?Q?JIlNr5/nNTIPQYTmeCbYmzH2Yf8yh1y2kqF4Hq8chsvDRpKz73Uc8Bhxqj?= =?iso-8859-1?Q?vdtBtN6qFkdzM/5C2Q4WjxUuVCrsnEOLb9ixCySOr5DYFQKoJinpJMvPKP?= =?iso-8859-1?Q?G+rzrbWBn3Qpt45QO/8GxiCGy/9IgsoPLlInVh74w19UJiuastRJ1bTVp3?= =?iso-8859-1?Q?aPY+Yb5KinURtQ12LKEC899mmYUBVAokd0RD6jifJN1cR8OD7gLQnlwWAJ?= =?iso-8859-1?Q?UBcJJadqizkKB8EdCu4eRhgFZAKX20feqscN7BFDpf3ACYkuTWJo0K1B2O?= =?iso-8859-1?Q?3Xdd3Ackk65lkKTCtQKip/LAAzr1+tzOsQNGj2CqNsOEHgAXV+2iaz0zE3?= =?iso-8859-1?Q?6vBTVeRgqBfdmRuuYr0/aVLOc/ylWCAUVWrAnKce1/nILHaUvuXF1ZHkfX?= =?iso-8859-1?Q?2TEhqyCNtiSIpAWALCarqqASX3uk1cLNkwrGoSfs8Yya5p4=3D?= Content-Type: multipart/alternative; boundary="_000_CP8P284MB2496EC00918E9439500DF0E2EC5F2CP8P284MB2496BRAP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-0f7b9.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 88c58c36-c078-44a4-3ddb-08dc39721ab0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2024 22:02:21.6229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1586 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_CP8P284MB2496EC00918E9439500DF0E2EC5F2CP8P284MB2496BRAP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sat, Feb 17, 2024 at 02:53:43PM +0000, Maiquel Grassi wrote: >> The "pg_stat_ssl" view is available from >=3D PG 9.5, and the "pg_stat_g= ssapi" view is >> available from >=3D PG 12. The "compression" column was removed from the >> "pg_stat_ssl" from >=3D PG 14. All of these cases introduce greater comp= lexity in >> maintaining the SQL. The central idea from the beginning has always been= to show >> the user all the information from \conninfo and extend it in \conninfo+. >IMHO we should use the views whenever possible (for the reason stated >above [0]). I think it's okay if we need to fall back to a different >approach for older versions. But presumably we'll discontinue psql suppor= t >for these old server versions at some point, at which point we can simply >delete the dead code that doesn't use the views. >> The absence >> of the "compression" column in version 14 and above makes dealing with t= his even >> more complicated, and not showing it seems to contradict \conninfo. >I would be okay with using PQsslAttribute() for all versions for this one >since any remaining support for this feature is on its way out. Once psql >no longer supports any versions that allow SSL compression, we could >probably remove it from \conninfo[+] completely or hard-code it to "off". >> SSL support has been available since version 7.1 (see documentation); if= there was >> support before that, I can't say. In this regard, it may seem strange, b= ut there are still >> many legacy systems running older versions of PostgreSQL. Just yesterday= , I assisted >> a client who is still using PG 8.2. In these cases, using the "pg_stat_s= sl" and >> "pg_stat_gssapi" views would not be possible because they don't exist on= the server. >> I believe that psql should cover as many cases as possible when it comes= to compatibility >> with older versions (even those no longer supported). In this case, conc= erning SSL and >> GSS, I think libpq is better prepared to handle this. >At the moment, the psql support cutoff appears to be v9.2 (see commit >cf0cab8), which has been out of support for over 6 years. If \conninfo+ >happens to work for older versions, then great, but I don't think we shoul= d >expend too much energy in this area. [0] https://postgr.es/m/20240216155449.GA1236054%40nathanxps13 ----//---- Hi Nathan! Sorry for the delay. I will make the adjustments as requested soon. Regards, Maiquel Grassi. --_000_CP8P284MB2496EC00918E9439500DF0E2EC5F2CP8P284MB2496BRAP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 17, 2024 at 02:53:43PM +0= 000, Maiquel Grassi wrote:
>= > The "pg_stat_ssl" view is available from >=3D PG 9.5, and= the "pg_stat_gssapi" view is
>> available from >=3D PG 12. The "compres= sion" column was removed from the
>> "pg_stat_ssl" from >=3D PG 14. All= of these cases introduce greater complexity in
>> maintaining the SQL. The central idea from the = beginning has always been to show
>> the user all the information from \conninfo and= extend it in \conninfo+.

>IMHO we should use the views whenever possible (for = the reason stated
>above [0]).  I think it's okay if we need to fa= ll back to a different
>approach for older versions.  But presumably we= 'll discontinue psql support
>for these old server versions at some point, at whic= h point we can simply
>delete the dead code that doesn't use the views.

>> The absence
>> of the "compression" column in versio= n 14 and above makes dealing with this even
>> more complicated, and not showing it seems to c= ontradict \conninfo.

>I would be okay with using PQsslAttribute() for all = versions for this one
>since any remaining support for this feature is on i= ts way out.  Once psql
>no longer supports any versions that allow SSL compr= ession, we could
>probably remove it from \conninfo[+] completely or h= ard-code it to "off".

><= span style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 11pt;= color: rgb(0, 0, 0);">> SS= L support has been available since version 7.1 (see documentation); if there was
>> support before that, I can't say. In this regar= d, it may seem strange, but there are still
>> many legacy systems running older versions of P= ostgreSQL. Just yesterday, I assisted
>> a client who is still using PG 8.2. In these ca= ses, using the "pg_stat_ssl" and
>> "pg_stat_gssapi" views would not be p= ossible because they don't exist on the server.
>> I believe that psql should cover as many cases = as possible when it comes to compatibility
>> with older versions (even those no longer suppo= rted). In this case, concerning SSL and
>> GSS, I think libpq is better prepared to handle= this.

>At the moment, the psql support cutoff appears to be= v9.2 (see commit
>cf0cab8), which has been out of support for over 6 y= ears.  If \conninfo+
>happens to work for older versions, then great, but = I don't think we should
>expend too much energy in this area.

[0] https://postgr.es/m/20240216155449.GA1236054%40nathanxps13

----//----

Hi Nathan!

Sorry for the delay. = I will make the adjustments as requested soon.

Regards,
Maiquel Grassi.
--_000_CP8P284MB2496EC00918E9439500DF0E2EC5F2CP8P284MB2496BRAP_--