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 1rY5rE-00EKeb-P0 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Feb 2024 14:58:33 +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 1rY5rB-000w9p-7W for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Feb 2024 14:58:29 +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 1rY5rA-000w9g-R0 for pgsql-hackers@lists.postgresql.org; Thu, 08 Feb 2024 14:58:28 +0000 Received: from mail-roabra01olkn2050.outbound.protection.outlook.com ([40.92.96.50] helo=BRA01-ROA-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 1rY5r7-0068vq-S5 for pgsql-hackers@postgresql.org; Thu, 08 Feb 2024 14:58:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=impkW14NOrLyWKiJKmXfFTbypYzcoGqw4N+plCXpcQX6kvA1swJzUH1wq1IO3FiLGou6GVqu3gHWc8bU5YneaOo4ZfdtlYxQHboLh1p/8AlHh33UjcwBd3WH3vTkz82n/R3pAlH0pqyjPxeardx9Bptty0u9E/nmbhoBR+vicChIL/3kVQzvVg2v5tpvsYw8hd50tT+f3TlKyIjmObChZ6nz6KcPXcLSE+bVlQM8lCRfXlZkBTAdKXESRFvq1GfmX87fscn6qDw8Q5MWlRJ/LaDbxKpDB5Z/ux7ylvjFvbsXe50TdpR43mdCI+gBvH9kpwnn+Lus5sdRKaiczcfR4g== 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=DaYlRetsHBvlfUJvhJj7M7wU93ervjP6baMfR7b5Hx4=; b=R5QsbxU0gY8vJEoNnr51hIWBOVjI+h2j85kqCdtb6NzJXg0Cy0MBDn5WbjAQiA5tyumyYDXVRj8iTSRkzB1+0mgJDyqVH5u8ukbb9vxj1CfLQ6QtbFgW68Iwqd7vpQmNvQmfycBVWqGZSoQADUu3J8D586u7wElbQykqsNRhA3v/giyAm2ilxfOw68uHKe3I77/AHucHY6M/fIOv4sBE2Pl0r89mJ78NpD67uf2kFvM3Id6tHD6Ek1/tupBuEhLR2sPc9BwfDiSZ4q0cIHErLQqo7Pd+hqkArzkMfJ0a1YCrs4fy16iOt1ASr/CuArFGJ3ZY1BkuN1NjKp//fTmv0w== 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 CP5P284MB3268.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:2ea::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.24; Thu, 8 Feb 2024 14:58:19 +0000 Received: from CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM ([fe80::ce6:bf75:3d4a:97cf]) by CP8P284MB2496.BRAP284.PROD.OUTLOOK.COM ([fe80::ce6:bf75:3d4a:97cf%6]) with mapi id 15.20.7249.038; Thu, 8 Feb 2024 14:58:19 +0000 From: Maiquel Grassi To: Pavel Luzanov , Nathan Bossart CC: Erik Wienhold , "pgsql-hackers@postgresql.org" Subject: RE: Psql meta-command conninfo+ Thread-Topic: Psql meta-command conninfo+ Thread-Index: AQHaWRQuU7L2MD2CX0quiO/hLxQK8bD9n9eAgAAOagCAABlrgoAABsOAgAABrYCAAAkRMoAAAaIAgABfmwKAAJe3AIAAHVoLgAAnEwCAADA+O4ABA4CAgAA4UGM= Date: Thu, 8 Feb 2024 14:58:19 +0000 Message-ID: References: <20240206181919.GA3853632@nathanxps13> <20240206210605.GA3903769@nathanxps13> <20240206211205.GA3903996@nathanxps13> <20240206215022.GA3452@nathanxps13> <852cabef-f596-4826-9a54-d3f75d9a6cc8@postgrespro.ru> In-Reply-To: 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: [YEDnKTy1GQUSe5DNvRFlBvKBXfYCvsNW] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CP8P284MB2496:EE_|CP5P284MB3268:EE_ x-ms-office365-filtering-correlation-id: 4a127789-fdb4-4aec-baff-08dc28b6636c x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8Jw5E6cMhlExXacM+0frkl/UEpOlH+P71IueRcyaArMZPrnvNmKLBQQBPHtgrEjCLE1yKWu7WfcioCj5DTOImW/EClgC8+uBk+yIC0p4sdrypF4naFqOqy/1VMBiWLVz0GH6AYChW0qKFJwwJAvvNTn02rTx6fL9PS9fByDlootY1f+beYxRiLZcY3icIqEaKVea4TaRXfYFS3xeJHBNX5m55zLuT7ptAn7P8gzvgngnoNKVaObN1pE3IJHjNoRWElSlwVx4VWxINyzg8vGCxRjrdor8VoP9IGP/Qy75hd7WWOKeg8YiaWgWmOZN4wtk1YJiNcLOodvg8JPe/4xSGZGSxJsfQF9WbAAHEvAV6J5PCqbwiHpGkGbL+71/6Ado+F3LnaOSjoAyiORy7PfONIbK+AgW01zc9ifOiHlK3QkpryCh1cjQRwxapvUTdXzCea4rJqS3XXd4cJagPNckYcnRR6uMWh7PgwBhbDNUpIeJU6rGyzoUgOhlW/dWVRM7O/0ZtcwbhxbQTPs3oS3Pj27YKWwA8zdroztL//CNM4x+VB3RrWs4B36pEjy3KNwD x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?7/Xk6NsGj3y18opJ2uxMgrVDbCG/hoFQsyhgQYSJAd37Pkjp3SAf1euhDB?= =?iso-8859-1?Q?o3Y1XIFRroq7BG2g8UWIQ/A4xODBWAM70MRixpi9uSL+SWd6dgUR4Grd6T?= =?iso-8859-1?Q?iRL4pC3AGweaxS7KC9EknRDyEPxFK+D2W69obxB1xdi5lpBgMmAhg+37vQ?= =?iso-8859-1?Q?gAit5k+r9996J0FJ4sVGsbuxeLGT/HQH+53RnxQOBWlH1MU36Dq7cepno8?= =?iso-8859-1?Q?xbyzeuPqeb5VsQKb0h1BYn0O1nBkqO/x5i6L8OM3L5AngQalhylP/K3x1O?= =?iso-8859-1?Q?SardVjizT+MH+CyGWt2zV/rIdscUjqnTGMpH0FsnxTUALD/lyoqld9mizN?= =?iso-8859-1?Q?ogerHVT+AGWbSJ+fk2eJutS1pb1SXn/dpvD7nmMky5fPQxdhhPs7UdeKQw?= =?iso-8859-1?Q?AUQ3I1PVVy4w+3zkZLtKKJZzO8pTcO/D4sPLYU6i1cFKNBHF9xep1PfJsS?= =?iso-8859-1?Q?RJKc1QDxXsF0wjy43yj3JEnm19AcdUz4yTNeIwxnISIjsrujuUv9P4wyCT?= =?iso-8859-1?Q?Izfj67a0Ce6dpk13gzUBsaygyNFEtxkdfd+YeB0rpHGK5q9t20BJ7MfFnc?= =?iso-8859-1?Q?k7OHbJauzFA0+zpAlMGbmpRLeh3bAywqxhnjKS8aDF83Dr5x/I+glJWcP3?= =?iso-8859-1?Q?27k8XlbFK/yhVSGGF/NZn1Lpv8WSnSvY9/TAzYLGqr+yeh+P2ABsB8Ckf7?= =?iso-8859-1?Q?I0dwzjbIdRlF/VwL3DMcmBtG9K7ch+qk+ZxPWNlZkYZNp0f7T6n8QhVi0A?= =?iso-8859-1?Q?gAOmpibWFfJuHxPu5t3glOZo9htXebY1RwjMb2ZbrHnOwBdWHqciptAigX?= =?iso-8859-1?Q?/E/+etQrC3KKhbX/2znpb2ikkyWtTY9DWtuzYHxle36tDn96PRhIAabS5I?= =?iso-8859-1?Q?+liC7byRfeYdI5/WVDD2gmwh5PLDVwLga6+g5+3ROzKGchZb3Uwp05dyve?= =?iso-8859-1?Q?maXw2mEp2AKXWnY989cwM1qPA3SLKnDq+l1K79iRWV9IKStDGMHEnFpQam?= =?iso-8859-1?Q?IebhDEFe/w3kwidyjwcr/I+TB6Veooh1AuFCVdj6FAdHat4/75dMuRsOvF?= =?iso-8859-1?Q?Z/IzOzcv+EvPPXCEuxSV7o2cenEkRiEz6lD/LW8/bsMybMq6EGllVOuoeV?= =?iso-8859-1?Q?uvD6nivwmbwRIAyCXTFL3tEDOVR/UqWZzcBzBBCQBlNFij7MztRTgJEIKS?= =?iso-8859-1?Q?Xccm3Uq311vrD5pE7VC5HzwrjFYjCgEJ9OVyG85o1M20ix9qCpLNXUgnqM?= =?iso-8859-1?Q?BJ2P4LOtbVAA1bi3AQ3w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CP8P284MB249652F5F0BE828C20A38348EC442CP8P284MB2496BRAP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.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: 4a127789-fdb4-4aec-baff-08dc28b6636c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2024 14:58:19.6639 (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: CP5P284MB3268 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_CP8P284MB249652F5F0BE828C20A38348EC442CP8P284MB2496BRAP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hi, > On 07.02.2024 23:13, Maiquel Grassi wrote: > Regarding the "system_user" function, as it is relatively new, I added > the necessary handling to avoid conflicts with versions lower than versio= n 16. > Yes, that's rights. > > A couple of doubts about the implementation details. > But keep in mind that I'm not very good at programming in the C language. > I hope for the help of more experienced developers. > > > 1. > + if (db =3D=3D NULL) > + printf(_("You are currently not connected t= o a database.\n")); > > This check is performed for \conninfo, but not for \conninfo+. > > > 2. > Some values (address, socket) are evaluated separately for \conninfo > (via C functions) and for \conninfo+ (via sql functions). > It may be worth evaluating them in one place. But I'm not sure about that= . > > The final version of the patch will require changes to the documentation = and tests. --//-- Hi Pavel, First of all, thank you very much for your observations. 1. The connection check for the case of \conninfo+ is handled by "describe.= c" itself since it deals with queries. I might be mistaken, but I believe t= hat by using "printQuery()" via "describe.c", this is already ensured, and = there is no need to evaluate the connection status. 2. I believe that by implementing the evaluations separately as they are, i= t becomes easier to perform future maintenance by minimizing the mixing of = C code with SQL code as much as possible. However, certainly, the possibili= ty of a better suggestion than mine remains open. Regards, Maiquel O. Grassi. --_000_CP8P284MB249652F5F0BE828C20A38348EC442CP8P284MB2496BRAP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> Hi, 
>=
; On 07.02.2024 23:13, Maiquel Grassi wrote:=0A=

> Regarding the "system_user=
" function, as it is relatively new, I added=0A=
> the necessary handling to avoid conflicts with versions lower than ver=
sion 16.=0A=

>=
; Yes, that's rights.=0A=
> =0A=
> A couple of doubts about the implementation details.=0A=
> But keep in mind that I'm not very good at programming in the C langua=
ge.=0A=
> I hope for the help of more experienced developers.=0A=
> =0A=
> =0A=
> 1.=0A=
> +			if (db =3D=3D NULL)=0A=
> +				printf(_("You are currently not connected to a database.\n&q=
uot;));=0A=
> =0A=
> This check is performed for \conninfo, but not for \conninfo+.=0A=
> =0A=
> =0A=
> 2.=0A=
> Some values (address, socket) are evaluated separately for \conninfo=
=0A=
> (via C functions) and for \conninfo+ (via sql functions).=0A=
> It may be worth evaluating them in one place. But I'm not sure about t=
hat.=0A=
> =0A=
> The final version of the patch will require changes to the documentati=
on and tests.

--//--

Hi Pavel,

F=
irst of all, thank you very much for your observations.

1. The connection check for the c=
ase of \conninfo+ is handled by "describe.c" itself since it deal=
s with queries. I might be mistaken, but I believe that by using "prin=
tQuery()" via "describe.c", this is already ensured, and the=
re is no need to evaluate the connection status.

2. I believe that by implementing the evaluations separately as the=
y are, it becomes easier to perform future maintenance by minimizing the mi=
xing of C code with SQL code as much as possible. However, certainly, the p=
ossibility of a better suggestion than mine remains open.

Regards,Maiquel O. Grassi.
--_000_CP8P284MB249652F5F0BE828C20A38348EC442CP8P284MB2496BRAP_--