Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ot4OO-0005iC-S8 for pgsql-odbc@arkaria.postgresql.org; Thu, 10 Nov 2022 10:02:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ot4ON-0003XC-Lm for pgsql-odbc@arkaria.postgresql.org; Thu, 10 Nov 2022 10:02:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oswUw-0004hL-OR for pgsql-odbc@lists.postgresql.org; Thu, 10 Nov 2022 01:36:55 +0000 Received: from mail-sy4aus01olkn2174.outbound.protection.outlook.com ([40.92.62.174] helo=AUS01-SY4-obe.outbound.protection.outlook.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oswUs-0004xi-Ed for pgsql-odbc@postgresql.org; Thu, 10 Nov 2022 01:36:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fa/R9T+ndDx1gfgJb4KBiw820t0Fy1o9uGp2GGIkmIWDHTFpkxUzpOVTMoUOo8yVPzx7RMdi+uEc2R/72Cth8e6nyC1h2EFU0Kc9EqaXQE83ftr0Q2WZkvfqKcvbNTB9qNjSBN4QISUc/mVkVBNyJp8iGMiPElBkrRwVagpCiGbL7i3l4ciGBthife4mNYlNUL63AN2UlLPLUH0uI15uESgTkT5cj+F21MqpsBkiAx3sB74WjPAdgMpVll2XjrogEgYalgxCMQoNUwCmXF6LdQ8Z9aG0R7lw+V3wFsfR8Go99a/CKRN/m82fQFFbDxMrfsV+b4D4wT5qeMjyZ4l9sA== 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=0MRizk+RaNbvatHvNr2rw2bSuMiGI8TsMSvBTnjec7I=; b=ZI1ppGAXv1LuVRfGOUOvWujh/Gdi0d39saJAAvFoiyM7XegN6/8rl6fJ0X69GSJt8THIdl5lJBxG9+JwGHj5nW6DJ1e+t7ZzoWtd8EfLrOHiHPhHQN5SsFfcHdRMJv7IZvf+Ojhsu9Szowne4kASbbJvArynCnOnQAODtZM5BauJhz6T1R1UTa9S/1g4KdSfMJyVtsNwAK2DVarVtJsagbMtQU+FnrOCleBUJObHi1BhHd2kylEdbJFlp8jolH3vY6Lt+hfG6iOBjC8KbXqp5ZJEFn1lR01hJ9ySP8Ws7TwrB1090W8OzYPZymA10o3bcl8ko8aZWfDbXV5B0g8Vvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0MRizk+RaNbvatHvNr2rw2bSuMiGI8TsMSvBTnjec7I=; b=dHdROD8g0yuY4sLu9MW9hWM5MYLfqxhQRMJoI1TLJvl6q+cA1oPAO0sGmdsmSIVsf1CqMAodFOIM/LXH0YNOo5JTcjg3/lPwHiiaMxiobI02FoHGjgB0PVSNikHemYAzvbMTH5ydUgRaNre8FdFOdFKVBqF4+xSvLTq7Ky6/IqOSlydURBv1et+7xbvsk6zYEqHkzDAmaKvsorkAfKmgf2GFggNjAQ2PA7A4RQbjje+Xz50Ls94N7ZwRfCHCPb+IJ+Bjwgi83FEgzkD3Bje8Bah+/nSf/ublzpTfPtXNqT6GlhkwZ2MsdRdIHq5NbqLuDFwF2fqGtanYEVt4yOytAw== Received: from MEYP282MB4042.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:172::14) by MEYP282MB2454.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:11d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.27; Thu, 10 Nov 2022 01:36:44 +0000 Received: from MEYP282MB4042.AUSP282.PROD.OUTLOOK.COM ([fe80::e1b9:e200:f521:aab9]) by MEYP282MB4042.AUSP282.PROD.OUTLOOK.COM ([fe80::e1b9:e200:f521:aab9%9]) with mapi id 15.20.5813.013; Thu, 10 Nov 2022 01:36:44 +0000 From: Chiang Chan-i To: "Wal, Jan Tjalling van der" , "pgsql-odbc@postgresql.org" Subject: RE: column_query buffer in PGAPI ColumnPrivileges Thread-Topic: column_query buffer in PGAPI ColumnPrivileges Thread-Index: AQHY8+nmARMu7u25gUeKi4RuOTYED643IUcAgABAX0c= Date: Thu, 10 Nov 2022 01:36:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tmn: [LfpUOfGDOIQMatVIDOZ/J90AD1nN2fJP] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MEYP282MB4042:EE_|MEYP282MB2454:EE_ x-ms-office365-filtering-correlation-id: 9deada27-231c-439a-e270-08dac2bc063c x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8ERih76ul6znpkOV/OT+9Zi5JlcAGV3xKVFBhag+3s/Xhc4nE6MHRMBdwqf8iDLH+/WhvIHypsZlOjx3SVexaJA3rtyvGfsF5hTlEwoVifrDtbltEaJcds7+MxoCbHHqtNE/gxLY19x2ASrSCWYaTQwjvu6oKZUcZP/Cuxe/lKJYL9bu8wMxUw5w1CzYSIy7L39JoSYaJgi7qWfz8m/GN/UtYNwuSRJjOFGk4DlbeTns7lc1DBIeLT/ROgWpm2zq2Pq8Lrxbo8WTCmZTTAayJ+YfN/p+l7PPy1M4X7UxoPfQmmaUVwq5Vm4Q7U35GC0UISntAiBr+d1QIfhxaiwZXSpu6lfT4TZ47yFDAtMp33miflgQA5DtrWZvok3hhH8Hy3l8coJuiEg6XNYfPkGj6E5qWNvYi12xEiIGz19KNikiDUdaE+MwpYIHTy/R4B4pKIWthqL7oKEgOUgc2+ql+X5fjf2Rd6SCuOfmKkeYiNedzNc3L7tEL3zsD6c+v9PUz0BDiQkiGuPWnogcUWOAkC17jef3+nfWV46Ect6g3a+pzn0BeJfBsnrqm8JHpyegB/scwQauZLxfm9IQVLw++r9vGgsUwAfjUcD6JJSU9Xjstt+EH4ERhrhCNfLGqVpdSy76i7697Au1n8VAmS02nd/O8XSuMb1FHW0FRSo1v6RVO1NxYsHa5DOICfMUIf20 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?RmR6eWQ1d2c1WUc0WmNHWlhhQ0MvQ0lNWXlranZwNDNCK01wcGV6dHJi?= =?iso-2022-jp?B?ZnJJMG9wU1RDNUpmNjg0R2dGZ3NLL09jU1FlOFFCd0pINmc2UHlHbkdn?= =?iso-2022-jp?B?WStpbXBjaDlNY2xWYUQ4bUFIcEoxc3JNdVl1azRUcHVjakVueGVqYjdv?= =?iso-2022-jp?B?bWdkb00yLzYzZ0ErQ2ZsamZGQjEvUE5xdEZLUHpUQmF6NXNSRzZ5Y0VB?= =?iso-2022-jp?B?SzZOaFFVckJEbmVWYkRYNVduTFVNanVLVDlocnJVVkRWZDRlUE16S01y?= =?iso-2022-jp?B?dzVOZ3B0cUZLMkRsSlNVbGZnd0tGT1JIY1NiRFdQcmdlTmg5N3YvaFdx?= =?iso-2022-jp?B?OVZPT1JPd3hWSktFcjNPa2NxWC9WM2dkZmo2QVpyTXZBSzIrWlUxMjNU?= =?iso-2022-jp?B?MDVmeG9VYThqOHoxbk9kVlArVzE3VjdCLzJpVDU3am4zNFlnbldCMkNX?= =?iso-2022-jp?B?Z1EyWXRkNlBqaXNiakRMUlh3U3VzU1RETEE1a29mZ1h2c0hJMzhiSjJ6?= =?iso-2022-jp?B?d2w3SmIzRjViS0Q0T3gxZE5FTDBSVUJkVlZjRXFDMitvSE1qSWpxVDhr?= =?iso-2022-jp?B?NGxaWlF2U0o3OW9UQ1laM3VtRnVJdEhDVTJDZUszQzB4YnlCaFFweFB6?= =?iso-2022-jp?B?MW9LSlFqR1FLZHV0MkVHRFJyNGlvMUVmZXpUYzN4Z2FqMm1XM0hqV1R6?= =?iso-2022-jp?B?eTNnMkVjM2llYlc3MEJqQlE4dFFIdUgxTjhMUEVNZUFDT25xUWY0MHRP?= =?iso-2022-jp?B?L1k1WUxFVGZ6cGcvTTg3UE5hM0pGWkdhV2tJWjc1VkIzOWRXZjdadEtJ?= =?iso-2022-jp?B?Y1RlVm5oYjF1WEU3dW05NTNVOVZsang1YWpWY1BxK3FNcERwSDVnRjNX?= =?iso-2022-jp?B?b0lZVmhwRjJvMXczQU8vU29QcmUveHY5cldZbkpGeFAxeGpCdjhtaFhp?= =?iso-2022-jp?B?Q3RvYkpIMjVPK3ZPRnRwaVNnUXUzVjNQOHRyaWozeVhNMEcwU1I1Vkt2?= =?iso-2022-jp?B?ZCtaRUgzWHhuRWszKzFBV1pwS3FUUXUzRVIvNXVwNHhOVlRmSEhyYWc3?= =?iso-2022-jp?B?cjQvK3BDYUdzWDl2M0ZYMDUyQnpjd0JSRWxwY0p0TUVBSU5nUUYxVU5H?= =?iso-2022-jp?B?M3Y5V0hxNk13NlNDVy9neW11VENSbFVmOFVZVlNraTd3NFhUOFZKcTRW?= =?iso-2022-jp?B?MXdHaHo5TVYxSytRUTE2OHRDOTVFM3phMmRwcmY0MW9yOGhIN3ZKblEx?= =?iso-2022-jp?B?MG1yVzZZWjR2a05iZk9MNmJtcndWeUhxamhLWGF6NlF0VWd0dU1qQVhy?= =?iso-2022-jp?B?enhIeXFjZDcvdXhZK0FiMG5OSGVLUXB3VGxBU0ZzZzZnM0QwbkliTDA4?= =?iso-2022-jp?B?bUNYVEg5ZW5jTjRlZlJZQ0YwcnFqQzhGRmZ4NlJQYUhVN1dudU5yVlZu?= =?iso-2022-jp?B?VjJhaFcwcU1xL1VRUjBsNXdkRWIyUWhCOTc1cUpDOVNWOEU2M3ZLaUJD?= =?iso-2022-jp?B?emhSNEJmbC9ad3d4OHpJZkp2TXl0LytjaHM2WnA3N3ozdUw3NlpOVHZv?= =?iso-2022-jp?B?azRqTjhMb0tPSlB4WmpxTStWdDhWVFh2bXpEY2ozc2duUjMzKzZBNElZ?= =?iso-2022-jp?B?UTNRU2RWSXRaYU5yVXVZNWtreDEvQXJJemFLZklKTC9TRTE2T3JKK3No?= =?iso-2022-jp?B?M0lDOXFkTC9EeGpJY24waUFKQlNVQWluSy90bnZaZWkveFl5UGFsRGtF?= =?iso-2022-jp?B?TmY5Wnh6cTc3Z3paNXVDQ05JSDc4VVVhWHUyN2VZditITFZ3cFZrSnBj?= =?iso-2022-jp?B?LzRYRVdQZk9SejhOZWpRdXBTV0dVRzArQTNFc1kyL0Q2U21Edmh5dXBF?= =?iso-2022-jp?B?OFJmM1ZGOEQ1amNhQ3oyTEZ3M3JJY0pIa3Y3VWFtYU5jVE1oYS9KN2ZM?= Content-Type: multipart/related; boundary="_004_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MEYP282MB4042.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 9deada27-231c-439a-e270-08dac2bc063c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2022 01:36:44.0015 (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: MEYP282MB2454 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_004_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_ Content-Type: multipart/alternative; boundary="_000_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_" --_000_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Dear Kind regards JT, Thanks for your help and patience. The error of SQL Command I mentioned is here=1B$B!'=1B(B 3733 if (escSchemaName) = =1B$B"-"-=1B(B-- table_schema 3734 appendPQExpBuffer(&column_query, " and table_schem %s'%s'", eq= _string, escSchemaName); jiang=3D# select '' as TABLE_CAT, table_schema as TABLE_SCHEM, table_name, column_name, grantor, grantee, privilege_type as PRIVILEGE, is_grantable from information_schema.column_privileges where true and table_schem =3D 'public' ---->>>> Maybe = table_schem[a]=1B$B!)=1B(B and table_name =3D'test' and column_name =3D 'a'; ERROR: column "table_schem" does not exist LINE 5: and table_schem =3D 'public' ^ HINT: Perhaps you meant to reference the column "column_privileges.table_s= chema". jiang=3D# Sent from Mail for Window= s From: Wal, Jan Tjalling van der Sent: 2022=1B$BG/=1B(B11=1B$B7n=1B(B10=1B$BF|=1B(B 5:45 To: foxi_yiyi12081003; pgsql-odbc@pos= tgresql.org Subject: RE: column_query buffer in PGAPI ColumnPrivileges Dear foxi_yiyi12081003, I=1B$B!G=1B(Bm not an expert on the inner workings of this specific driver,= but in my opinion this is probably correct. The query that is defined inside appendPQExpBufferStr, asks for data from c= olumn table_schema to be returned using a different name: TABLE_SCHEM. When the results of that query are used further down, the correct name to u= se them will be that new name. When the query is run against an running instance of a postgres-database it= gives results (over 9000), here limited to just 5. select '' as TABLE_CAT, table_schema as TABLE_SCHEM, table_name, column_name, grantor, grantee, privilege_type as PRIVILEGE, is_grantable from information_schema.column_privileges where true limit 5; "table_cat" "table_schem" "table_name" "column_name" "grantor" "grantee" "privilege" "is_grantable" "information_schema" "routines" "scope_schema" "xxxxxxxxxxxxx" "xxxxxxxxxxxxx" "UPDATE" "YES" "information_schema" "routines" "dtd_identifier" "xxxxxxxxxxxxx" "xxxxxxxxxxxxx" "INSERT" "YES" "pg_catalog" "pg_stat_progress_vacuum" "datid" "xxxxxxxxxxxxx" "xxxxxxxxxxxxx" "SELECT" "YES" "information_schema" "role_udt_grants" "grantor" "xxxxxxxxxxxxx" "xxxxxxxxxxxxx" "SELECT" "NO" "pg_catalog" "pg_namespace" "nspname" "xxxxxxxxxxxxx" "xxxxxxxxxxxxx" "SELECT" "YES" Kind regards JT From: foxi_yiyi12081003 Sent: 09 November 2022 04:18 To: pgsql-odbc@postgresql.org Subject: column_query buffer in PGAPI ColumnPrivileges Hi, Is that a bug in psqlodbc-13.02.0000 release version ? file: info.c : 3734 ? the SQL Command in the second appendPQExpBuffers =1B$B!Z=1B(B and table_schem %s'%s' =1B$B![=1B(Btable_schem or table_schema= ?? code: appendPQExpBufferStr(&column_query, "select '' as TABLE_CAT, table_schema a= s TABLE_SCHEM," " table_name, column_name, grantor, grantee," " privilege_type as PRIVILEGE, is_grantable from" " information_schema.column_privileges where true"); op_string =3D gen_opestr(like_or_eq, conn); eq_string =3D gen_opestr(eqop, conn); if (escSchemaName) appendPQExpBuffer(&column_query, " and table_schem %s'%s'", eq_str= ing, escSchemaName); if (escTableName) appendPQExpBuffer(&column_query, " and table_name %s'%s'", eq_stri= ng, escTableName); if (escColumnName) appendPQExpBuffer(&column_query, " and column_name %s'%s'", op_str= ing, escColumnName); if (PQExpBufferDataBroken(column_query)) and I also found the same condition in master branch=1B$B!#=1B(B [cid:image001.png@01D8F48C.1DC554E0] --_000_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Dear Kind regards JT,

 

Thanks for you= r help and patience.

The = error of SQL Command I mentioned is here=1B$B!'=1B(B

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        

3733=      if (escSchemaName)      &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;     = =1B$B"-"-=1B(B--  table_schema<= /span>

3734=          appendPQExpBuffer(&col= umn_query, " and table_schem %s'%s'", eq_string, escSchemaName);<= o:p>

 

 

jian= g=3D# select '' as TABLE_CAT, table_schema as TABLE_SCHEM,

&nbs= p;            &= nbsp;  table_name, column_name, grantor, grantee,

&nbs= p;            &= nbsp;  privilege_type as PRIVILEGE, is_grantable from

&nbs= p;            &= nbsp;  information_schema.column_privileges where true

&nbs= p;            &= nbsp;  and table_schem =3D 'public'   =        ---->>>>    = ;   Maybe table_schem[a]=1B$B!)=1B(B   

&nbs= p;            &= nbsp;  and table_name =3D'test'

&nbs= p;            &= nbsp;  and column_name =3D 'a';

ERRO= R:  column "table_schem" does not exist

LINE= 5:            =      and table_schem =3D 'public'   &nbs= p; 

&nbs= p;            &= nbsp;           &nbs= p;  ^

HINT= :  Perhaps you meant to reference the column "column_privileges.t= able_schema".

jian= g=3D#

 

 

Sent from Mail for Windows

 

From: W= al, Jan Tjalling van der
Sent: 2022=1B$BG/=1B(B11=1B$B7n= =1B(B10=1B$BF|=1B(B 5:45 To: foxi_yiyi120810= 03; pgsql-odbc@postgresql.org
Subject: RE: column_query buffer in PGAPI ColumnPrivileges

 

Dear foxi_yiyi12081003,

 

I=1B$B!G=1B(Bm not an expert on the inner workings of this specific dr= iver, but in my opinion this is probably correct.

The query that is defined inside appendPQExpBufferStr, asks for data f= rom column table_schema to be returned using a different name: TABLE_SCHEM.

When the results of that query are used further down, the correct name= to use them will be that new name.

 

When the query is run against an running instance of a postgres-databa= se it gives results (over 9000), here limited to just 5.

select '' as TABLE_CAT, table_schema as TABLE_SCHEM,

          table_name, col= umn_name, grantor, grantee,

          privilege_type = as PRIVILEGE, is_grantable from

          information_sch= ema.column_privileges where true limit 5;

"table_cat"

"table_schem"

"table_name"

"column_name"

"grantor"

"grantee"

"privilege"

"is_grantable"

 

"information_schema"

"routines"

"scope_schema"

"xxxxxxxxxxxxx"

"xxxxxxxxxxxxx"

"UPDATE"

"YES"

 

"information_schema"

"routines"

"dtd_identifier"

"xxxxxxxxxxxxx"

"xxxxxxxxxxxxx"

"INSERT"

"YES"

 

"pg_catalog"

"pg_stat_progress_vacuum"

"datid"

"xxxxxxxxxxxxx"

"xxxxxxxxxxxxx"

"SELECT"

"YES"

 

"information_schema"

"role_udt_grants"

"grantor"

"xxxxxxxxxxxxx"

"xxxxxxxxxxxxx"

"SELECT"

"NO"

 

"pg_catalog"

"pg_namespace"

"nspname"

"xxxxxxxxxxxxx"

"xxxxxxxxxxxxx"

"SELECT"

"YES"

 

Kind regards JT

 

From: foxi_yiyi12081003 <foxi_yiyi120= 81003@outlook.com>
Sent: 09 November 2022 04:18
To: pgsql-odbc@postgresql.org
Subject: column_query buffer in PGAPI ColumnPrivileges

 

Hi,

Is that a bug in psqlodbc-13.02.0000 release version ?

file: info.c : 3734 ?

the SQL Command in the second appendPQExpBuffers

=1B$B!Z=1B(B and table_schem %s'%s' =1B$B![=1B(Btable_schem or table_schema ??

 

code:

appendPQExpBufferStr(&column_query, "select '' as TABLE_CAT, tabl= e_schema as TABLE_SCHEM,"

                " table_name,= column_name, grantor, grantee,"

                " privilege_t= ype as PRIVILEGE, is_grantable from"

                " information= _schema.column_privileges where true");

  op_string =3D gen_opestr(like_or_eq, conn);

  eq_string =3D gen_opestr(eqop, conn);

  if (escSchemaName)

         appendPQExpBuffer(&column_query, &qu= ot; and table_schem %s'%s'", eq_string, escSchemaName);

  if (escTableName)

         appendPQExpBuffer(&column_query, &qu= ot; and table_name %s'%s'", eq_string, escTableName);

  if (escColumnName)

         appendPQExpBuffer(&column_query, &qu= ot; and column_name %s'%s'", op_string, escColumnName);

  if (PQExpBufferDataBroken(column_query))

 

 

and I also found the same condition in master branch=1B$B!= #=1B(B

 

 

--_000_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_-- --_004_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=135; creation-date="Wed, 09 Nov 2022 21:45:16 GMT"; modification-date="Thu, 10 Nov 2022 01:35:39 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACQAAAAkCAYAAADhAJiYAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAcSURBVFhH7cExAQAAAMKg9U9tB28gAAAAAIBb DRRkAAGqxD3OAAAAAElFTkSuQmCC --_004_MEYP282MB4042BC333C03F2D225071D7A92019MEYP282MB4042AUSP_--