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 1ot4IH-0005Dz-TM for pgsql-odbc@arkaria.postgresql.org; Thu, 10 Nov 2022 09:56:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ot4IG-0005lH-Kz for pgsql-odbc@arkaria.postgresql.org; Thu, 10 Nov 2022 09:56:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ot4IG-0005k7-18 for pgsql-odbc@lists.postgresql.org; Thu, 10 Nov 2022 09:56:20 +0000 Received: from mail-am6eur05on2105.outbound.protection.outlook.com ([40.107.22.105] helo=EUR05-AM6-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ot4I8-000218-6s for pgsql-odbc@postgresql.org; Thu, 10 Nov 2022 09:56:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gaD2NT1GCsI6rhDfLD50k6N6Kz+Dpz+IOctCbzB8dQxcqfr8B63LX3XAce35gtKMVSONFNVPqhwOkJMjxt+Rs5bTbe+NJee/7xRtAxvDZ+epuHAgKAv9Qx1wecqmHPyAR5hllYvhdStMuC+Wmt3MRa8KQSFGn3mNOEGPhu1OYUzYo4v/iquk8XKOnNAqmCLF73zRKHov69vt9UDNPbQJFSWgNK516aBxtdNCTtPd5xRIa+tP0BI6jKkhhgMbn55HsM1gDp7lPViO65QtlykgcynSkwDPUjj95basQtOGM7JNK8S1lzcKSwsJ6YiS/JL6hK+LFBaSMJ5pE0fV26nthQ== 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=7nqFf6wwDRea8V/2xaLAzm1tmevCBakax2IVUtFZ7Ck=; b=Ex13rDOrEsLkgJeR3KhrWEAPV9xqopisF7c8LAmlG3wE6QVLiAW5EMvxfmvN1GeUZTFK8wdH5QJSKyu7zUrG9k7DSab2c42XUMnrMtYier49seRd+pOiUkjLC43jBbYAHZFZ46wOcqET1/M+Ws16qZfEwNZMkC/+jikHwd9mtKxzzJoXcbkaWeRXDhhw+CCPHSfZGlLRFXEL69Y4MWOvhLm3WGncGAN+9oGW9kKfjbQ6vJ34XxwmaJB4fXdOcS2InzFPuassmvfKUD/xpVnJeOUIcqg0atGGUoX6wJPj7exOb7/JA+6ObqQL/6V9XrTNEc2NGwKzs137gxuJSQ5MUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wur.nl; dmarc=pass action=none header.from=wur.nl; dkim=pass header.d=wur.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wur.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7nqFf6wwDRea8V/2xaLAzm1tmevCBakax2IVUtFZ7Ck=; b=bAbKCNN884nz/uhwwMa25e+wsUlwjTe/5D7LR4NE7JDVJhzTIsBFi1/XFbG9f9NOsV5b6anyb06fT8+HD0g1nqc221+7A1NcPWHE/FnWy6NXHiAVtNH70Bl3CC5KlNMhQaiNwGnf+Nz8DSxizMgp6u8n9d85o8v33Hby5nuSmqE= Received: from AM0PR01MB5634.eurprd01.prod.exchangelabs.com (2603:10a6:208:171::11) by AS1PR01MB9442.eurprd01.prod.exchangelabs.com (2603:10a6:20b:4d2::18) 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 09:56:09 +0000 Received: from AM0PR01MB5634.eurprd01.prod.exchangelabs.com ([fe80::77ab:9538:84c8:629e]) by AM0PR01MB5634.eurprd01.prod.exchangelabs.com ([fe80::77ab:9538:84c8:629e%7]) with mapi id 15.20.5791.027; Thu, 10 Nov 2022 09:56:09 +0000 From: "Wal, Jan Tjalling van der" To: Chiang Chan-i , "pgsql-odbc@postgresql.org" Subject: RE: column_query buffer in PGAPI ColumnPrivileges Thread-Topic: column_query buffer in PGAPI ColumnPrivileges Thread-Index: AQHY9BePAfz2KQZpz0u2jmio5y6gTq43HkcQgABDUQCAAIoX8A== Date: Thu, 10 Nov 2022 09:56:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=wur.nl; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM0PR01MB5634:EE_|AS1PR01MB9442:EE_ x-ms-office365-filtering-correlation-id: cf331392-2fe9-477e-cb7a-08dac301caeb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oiVoYxLWmDW58kCdAVaUs2UeCuaoRzwsl/P1NmzEQC8Qvh7weXQfjIo8+yBbGEDEDcs4dTbLkdz4EzoNQ3aiGPYRvdb6dlHUZHoLAL7SnS8MdLevzn1r5GzK+bZB5h4X+mnxUquQfMKOpmnxgfMiEg6RLLKuhGOJbFNNs8ZLrfxm3cJZ19ank/yFxz0Y1RIhd1wY1Oo0KhTAzuyCpeveriMhlyhXSxAN7kATtMm8+pxyac+3eIyHwEhb/VQeU3+/Y0oekEeVUsQi86Bs5DhnKv4IzgFksAN8SByaRNbd7PCCQJP9aFn6v/jE4XKqQPKiH+dhxrTKrK8H3yM4R8sodL7tKlxu082hJfZAdd1bd72jjpvM25PaJ2hyWwY/qYoGxHW5cm+ZGTJUxmv1xIep9OuAWa/MOx1uGSkZTz6piRhlhTe5BIErmwnSTCHdcrAqIygJ8gm50KCzxoBsCeitPqO4G2Uf2dQ37PZI04Bz9rL6oJr2nSLLqRJFI4e9bFdkiP5yOFZvdW9xDpFXVeqVqfk6vO1doT2Wsq3N5f9RiKPES+j/67JtnxjrU3qE/5lgG5piaOi79qfeS4rbXdHqZ8B0jWUja/2BDR5pnsiPc0MH07uI+L9UoPsksBTd/6h786k9zyrMcx8O1L5OHaTBp0SdpNUpS2Z8B5izazVYGsszlpaWvCX6TYxkuYUMRSYfk9NBmxHAfS1cBCzDFL3Q7UiIUDmW2iC++E7UvmYEPaOLFFP7XjN84KuphN7bSqlff+T8lt4QFOmGtVZQp4Y3h+163n025zcxdvHarWd78pI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR01MB5634.eurprd01.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(346002)(39860400002)(376002)(366004)(396003)(451199015)(99936003)(122000001)(33656002)(38100700002)(166002)(478600001)(55016003)(53546011)(38070700005)(83380400001)(86362001)(2906002)(6506007)(186003)(9686003)(41320700001)(7696005)(76116006)(8676002)(8936002)(64756008)(5660300002)(71200400001)(52536014)(66556008)(41300700001)(786003)(316002)(26005)(110136005)(66476007)(45080400002)(66946007)(66446008)(579004);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?M2d5TkpNcXQ1T1c4L1VoMFBPaEx4ZTgzSHZCN0M5ekJaK2hMc25pMHdV?= =?iso-2022-jp?B?MGlzcUVZMklrK1FmWEJUNERBR2Q2SXV2N3Vpd1d1ODI4UnVYdnV6dklp?= =?iso-2022-jp?B?V2EwcVE4eWFSVWE1SXQvcnVPOEF5dVVZb3FOcjA0REMyWlNTOVp4QXJH?= =?iso-2022-jp?B?Yll6RlJHVWRaZVYzd2ExcUlJYWVpV3FZN3VtMzEwR3YyL1l1MlBvb0Ex?= =?iso-2022-jp?B?eFgvWUFEWW95MHpHT1hWSElOdFBTelJ6L3p3VlJwRUV2V3Ixd3l2RWFq?= =?iso-2022-jp?B?UzZBQlNQNTRrQStQUjRZdGVLV2JZU2gxdFZMWVQxbFdQdTlpZUpQd2JM?= =?iso-2022-jp?B?ck84OVJnek10RjVsSCtqT3dBZElONDNaN3RJZk5kN3B4S1FvalhsWGFQ?= =?iso-2022-jp?B?L3NwVTFiOGYyb01yUlFqLzQyVVJYZlpjVXY2aEVLcWdGL3lxL2pLN0FC?= =?iso-2022-jp?B?amxZdHN2NkJzeHpWN015NHY1a3QvZUNVVDR2WlNjQy9sQ3JTNWt4VEZF?= =?iso-2022-jp?B?RDNtSjByejRYYjdtSzJXQ1l6WEFxenRqblllT2d5eXJzbGhyVDdmNmUx?= =?iso-2022-jp?B?YlRSODJaeVl6U2lXQnhHQjU5YTYwQnZmeDBZSi9QYm96UFlTL3VpdHdl?= =?iso-2022-jp?B?a0psc0ptdEhIVUk0bFdJR2R4YURTTFdEcXEzVGZua0c0V3Zzamc0cUV5?= =?iso-2022-jp?B?NzdwcVYrREViZExsaWxKQVpIeTRlNm1TUjN2WGJmaWtOcmFGSGlVYXlW?= =?iso-2022-jp?B?SHh2VFBFV083a0FFbkJnOHAyR1dxSDJzajVkaENOSm9VanFHZGtXY1Jj?= =?iso-2022-jp?B?emJkY2d1L2FaaWMxWTNxUDNNaStuTTFRZHZNeXVkY25zckVvS3kyejd3?= =?iso-2022-jp?B?Z09FRjdxL2ZCaEFMTGFpejlzRlpsSnNVWDAwRHBTVm92bnNRTitIVTJ5?= =?iso-2022-jp?B?cytOOVB0eW51dnozMmdjb1pqV3JBeFFzdmlocW9HdGVLanE2eDBjZnRD?= =?iso-2022-jp?B?REIvUkFPYVNaY3g5Sm9WcXRLeFhycGZTK0ZyNWlFbjlHS1hVeHgzNlFW?= =?iso-2022-jp?B?dXZGanZOUjdQcTFlMWlVOGZsT3BkcXBiNXZkRTFnMjJ3bHduT1lXNkx1?= =?iso-2022-jp?B?V1QxdnFlQTcwTzRxd0dzUTVOWFlBTWFFVFZqQnhZOTczQWt4WXN5c3Na?= =?iso-2022-jp?B?OUd1aDN4RlFXWFZjMzN4T1JQVzRKMEhhdklCTlZmMTA0M0hyajF4a2d2?= =?iso-2022-jp?B?a1lXY2llSXVNVGVESERCTGtVbVE2MFFOYTJ5Nmw5d3RvMkFTM0tpN1A0?= =?iso-2022-jp?B?dFZVVW9manptZnh0cmtxZlNBdFZ2RXF0MEZMU1lzZnVyYXpWY2ZhYWcw?= =?iso-2022-jp?B?K1l3T1lpNE5zbDl1d1Y1L1lHMlNJK3MrL0ZHekdHeSt6WWJhSnpWbGNW?= =?iso-2022-jp?B?V0ZWYUVtbUdRKzR1bVFXamNGVGI2RFlJN2RBVnkzUWo2N3hwcWluOE9j?= =?iso-2022-jp?B?aFRvZGxoUFRUb3VvQ0E0YkhWVWkrbjhGckx6WGp4L2JRektRNlhFa2Rn?= =?iso-2022-jp?B?WWZlakdyTWRTNXJjMWU3eVNpRks2eU9wd3lmejNHcVZEUU1lSU5LZS9C?= =?iso-2022-jp?B?dDhkNE4zTkFPVEtaNVdlSm9JRU16cWwvSno5YlM2YWYrSlFuU1FGSm44?= =?iso-2022-jp?B?S2JpN3pPZ2xmdHMzcnpYSlZ5ajRpSFZPRDBGV3NtRXpkQUsvUUhSN2hH?= =?iso-2022-jp?B?enRsaEFFejN0V3FvclBUd2tYcVRkdENOM0dqR1VtcWdXWjc4d0p0TjU3?= =?iso-2022-jp?B?Q3llR1E4VWVVUHhlV09jRjJPTy9oWHROZldKTkNtQzVBdm9Reld3YmFo?= =?iso-2022-jp?B?WmFPZ1g4d3l6RE5maUVVODh1eFoxWU1qVXRQb1hRVVQrMjQvMStyaE1S?= =?iso-2022-jp?B?VU55bVFaRmkxci96V0VtRWh5UVA1ejRUbEkrandKUVRWdThkVExoRXNC?= =?iso-2022-jp?B?ejRlMk1FNjR4NFYwUEo1cjdnQzB4azZQK2taMVdRY0dxem1kQittTDlk?= =?iso-2022-jp?B?NHpjTEVGc0RmYTdxZ0Z3MXhrRTNZNHI0c1NIbG9KZU51SS9vblJYZXJ3?= =?iso-2022-jp?B?SXFTVEZIbCtCa1d2WlRuRW5PRTIydzhWVS9JMEpmbDl2MHdIai9mMFVZ?= =?iso-2022-jp?B?akg4RXVGWm5kcnE0RDNLc0p2NHNvR1ZzWXY4Q3Y4WWo1UEpGVm1HS1J0?= =?iso-2022-jp?B?czNRQVhSYmFwUmV2bTNaWHloRlBXS05SelVnVk5BdXEvWDV1aEJlN3B1?= =?iso-2022-jp?B?QlZ6L0J0VGIzZEZuUzFyV3NxVFZBdGxkcnc9PQ==?= Content-Type: multipart/related; boundary="_004_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: wur.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR01MB5634.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf331392-2fe9-477e-cb7a-08dac301caeb X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2022 09:56:09.2712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 27d137e5-761f-4dc1-af88-d26430abb18f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ap+utROe9rtICUY3G3QRl3R3NeOuNemDfKBhV43IpJkCRMx7xWders1nJhg7HLxdUSpXjMn0cSmWYMHF/vrR3wsvA/eb+XSNek4RoUDH1Qg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR01MB9442 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_004_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_ Content-Type: multipart/alternative; boundary="_000_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_" --_000_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Dear Jiang, Yes, you are right. I stand corrected. With that clause added as per line 3743, the query returns an error. When that missing =1B$B!F=1B(Ba=1B$B!G=1B(B is added, so table_schemA it y= ields results. Now we=1B$B!G=1B(Bll have to wait and see if this get noticed and fixed. Or you could consider making the change and doing a pull request. So that your find and fix get pulled into the code base? Kind regards, Jan Tjalling From: Chiang Chan-i Sent: 10 November 2022 02:37 To: Wal, Jan Tjalling van der ; pgsql-odbc@p= ostgresql.org Subject: RE: column_query buffer in PGAPI ColumnPrivileges 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 Windows 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@01D8F4F2.BF37AE70] --_000_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Dear Jiang= ,

 = ;

Yes, you a= re right. I stand corrected.

 = ;

With that = clause added as per line 3743, the query returns an error.

When that = missing =1B$B!F=1B(Ba=1B$B!G=1B(B is added, so table_schemA  it yields results.

 = ;

Now we=1B$= B!G=1B(Bll have to wait and see if this get noticed and fixed.

Or you cou= ld consider making the change and doing a pull request.

So that yo= ur find and fix get pulled into the code base?

 = ;

Kind regar= ds, Jan Tjalling

 = ;

From: Chiang Chan-i <foxi_yiyi1208100= 3@outlook.com>
Sent: 10 November 2022 02:37
To: Wal, Jan Tjalling van der <jan_tjalling.vanderwal@wur.nl>;= pgsql-odbc@postgresql.org
Subject: RE: column_query buffer in PGAPI ColumnPrivileges

 

Dear Kind regards JT,

 = ;

Thanks for your help and patience.

The error of SQL Command I mentioned is here<= span lang=3D"ZH-CN" style=3D"font-size:12.0pt;mso-fareast-language:ZH-CN">= =1B$B!'=1B(B

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

3733     if (escSchemaName) &nbs= p;            &= nbsp;           &nbs= p;             =           =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 TA= BLE_SCHEM,

        &nbs= p;       table_name, column_name, granto= r, grantee,

        &nbs= p;       privilege_type as PRIVILEGE, is_gran= table from

        &nbs= p;       information_schema.column_privileges= where true

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

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

        &nbs= p;       and column_name =3D 'a';<= /span>

ERROR:  column "table_schem" does not= exist

LINE 5:       &nb= sp;         and table_schem =3D 'pu= blic'     

        &nbs= p;            &= nbsp;      ^

HINT:  Perhaps you meant to reference the colum= n "column_privileges.table_schema".

jiang=3D#

 

 

Sent from Mail for Windows=

 

From: Wal, Jan Tjalling van der Sent: 2022=1B$BG/=1B(B11=1B$B7n=1B(B10=1B$B= F|=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 driver, but in = my opinion this is probably correct.

The query = that is defined inside appendPQExpBufferStr, asks for data from column tabl= e_schema to be returned using a different name: TABLE_SCHEM.

When the r= esults of that query are used further down, the correct name to use them wi= ll be that new name.

 = ;

When the q= uery is run against an running instance of a postgres-database it gives res= ults (over 9000), here limited to just 5.

select '' = as TABLE_CAT, table_schema as TABLE_SCHEM,

 &nbs= p;        table_name, column_name, grant= or, grantee,

 &nbs= p;        privilege_type as PRIVILEGE, i= s_grantable from

 &nbs= p;        information_schema.column_priv= ileges 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 regar= ds JT

 = ;

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

&nbs= p;

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 TAB= LE_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");

  op_string =3D gen_opestr(like_or_eq, conn);

  eq_string =3D gen_opestr(eqop, conn);

  if (escSchemaName)

         appendPQExpBuffer(&colum= n_query, " and table_schem %s'%s'", eq_string, escSchemaName);

  if (escTableName)

         appendPQExpBuffer(&colum= n_query, " and table_name %s'%s'", eq_string, escTableName);

  if (escColumnName)

         appendPQExpBuffer(&colum= n_query, " 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_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_-- --_004_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=135; creation-date="Thu, 10 Nov 2022 09:56:08 GMT"; modification-date="Thu, 10 Nov 2022 09:56:09 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACQAAAAkCAYAAADhAJiYAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAcSURBVFhH7cExAQAAAMKg9U9tB28gAAAAAIBb DRRkAAGqxD3OAAAAAElFTkSuQmCC --_004_AM0PR01MB5634D0C360CE54597E81B4EDDD019AM0PR01MB5634eurp_--