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 1oyeHw-0006BK-1G for pgsql-odbc@arkaria.postgresql.org; Fri, 25 Nov 2022 19:23:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oyeHu-0005CP-MZ for pgsql-odbc@arkaria.postgresql.org; Fri, 25 Nov 2022 19:23:02 +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 1oyeHt-0005Bl-Sd for pgsql-odbc@lists.postgresql.org; Fri, 25 Nov 2022 19:23:02 +0000 Received: from mail-vi1eur02on2070d.outbound.protection.outlook.com ([2a01:111:f400:fe16::70d] helo=EUR02-VI1-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 1oyeHo-0007gK-8M for pgsql-odbc@lists.postgresql.org; Fri, 25 Nov 2022 19:23:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BmPLJTkSxH9OcVSQ+hZn6uc/Z2yF2aM3nOPHSdw0+q8LrNAd+oSPK+fRtyXt1NNUYHLecqNWToXF67R0JA7a2KxOIZV0aTkocEl8OP0CbfLxdWlTFf0Ciu2YMnvuHdcuLtqhNof1GGjwV+vqSuwzmUPMs0jyh/02XbvXrWUTmHjGwpDsW7qcu5pwqtCIW7ms7WESF4nx6fW9bM5GAGNt4Xz0DL/TbyUVUNFimxN4VWf1TCYMOWrXhIN36d4H64yHkccLiiNtVuDJ6yYsvG8jjPA6hls8o0JZEehUzYx/e5ISZevkt4mhxTc5rLLdFheiHCJzXh2v9oGGbkPIfjD9Dg== 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=ABj693dC8U2hHPLCwZHH+vKuUZ0UcIF3bUBuxgCdqDc=; b=hjIZIzunag4H2Nv/MbZGfjhh34miZg3S8y43JZ2oFj5ZZt0MZZWuvaigjLfWVEh3qAq01enfWdUOptohmFnYkLjSRN5vK/gQrsVkijPWOrD+99N13XnDNBzACtzGwAlZ+QqEjyUAioEVs2ldEXF9e1tmtiks3GDl8qRv6mooT8LQDen6Ded1Yftwrix1KXZBQ+Nw1BOfuAw9jw4Jty2fz+vkX1tGp3MYfIMDsdQq091jDFNowc14WOCFfDgDVkI/F8nvI8ViWf/ybyRmFDjW1l4Cvv9eUZHNrwkQ72iG4q9U03q2zIs+ycimSV5LBGDMs4oKCD39kL1r2w4U41TANA== 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=ABj693dC8U2hHPLCwZHH+vKuUZ0UcIF3bUBuxgCdqDc=; b=f220HStrVSBzIalUEEfE8wljWt/OxBEtQ8GENb8WAQVYTHhZ4KSHmPMChXHV1vhmpDTNy45T+7F+UFQbt6x5MEWdeGfNMrDEPfdmu/8sByY/8Vx5LuSFq9SV73KrQwsTcDlDH+exqgASZmwvR8b9n++zgYF6EidphlIZ75C2gAE= Received: from AM0PR01MB5634.eurprd01.prod.exchangelabs.com (2603:10a6:208:171::11) by AS8PR01MB8123.eurprd01.prod.exchangelabs.com (2603:10a6:20b:37a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.15; Fri, 25 Nov 2022 19:22:48 +0000 Received: from AM0PR01MB5634.eurprd01.prod.exchangelabs.com ([fe80::1833:923c:c682:fa76]) by AM0PR01MB5634.eurprd01.prod.exchangelabs.com ([fe80::1833:923c:c682:fa76%7]) with mapi id 15.20.5857.021; Fri, 25 Nov 2022 19:22:48 +0000 From: "Wal, Jan Tjalling van der" To: Jon Raiford , Marsupilami79 , "pgsql-odbc@lists.postgresql.org" Subject: RE: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count? Thread-Topic: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count? Thread-Index: AQHY/osaIK7QKWDal0+AzVLXwV+Xnq5LHf7wgAPYfoCAARElQA== Date: Fri, 25 Nov 2022 19:22:48 +0000 Message-ID: References: <39e35073-0cac-5d64-9a72-b47ea671fb20@gmx.de> In-Reply-To: Accept-Language: en-NL, en-US Content-Language: en-US X-MS-Has-Attach: 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_|AS8PR01MB8123:EE_ x-ms-office365-filtering-correlation-id: d06c3b62-1c4d-4edb-3491-08dacf1a7027 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YGLEUUjRbUcEFflVFTZBLsO8HYhHDpJzs9CtU7Pgggf5K4Mi0bGjWfukVFa31ZiMt/h64qx6CQ7x3kqTHZx9OwvncMWjr2G2gyqp96om7WuujqNzt9Quc8FGL0bRURj1cpH72Lr7egmdfVwBPQQq29huCZbxWEDRzC1Y6EOJdQD5N7ExhFDv6WDByXAHRmuMyr6+WGwyt7CqBjvP+khdAIs8X3uozoLKeXkLKhoa6m0UMpLoShTdBNcpEt8qnoUv/j8q8WD/F5RiVKlNUsJ0jB/ma14ltnMsawNZ/TcxrEKkmHKAzSyvuaT0NJ1D3Zemz1zthKRDgm/QSApQ1S0DHFl1tmWp0E93XB1Mt0X4d/vV1gvEmh3KjAvN5Yt05iHAqjKimtrpsleFeYA2P3s4Aj3FNmEObNUuWPdPh2uYhX0MjfJ202dvjnGSrEWPQjWF4mAqSIZhdkiUVC4S7voTGowOjHUbW+4BMPXnY4iUpIPzYaAvKQ/l3OgviIJr7wjKO6hUlrCJvFGegSlv121hdprwWidBh/bHM/OeQFPK1OaigH6u2Axx4ieYZ8y7TAamsbt08o/oP5c/9j9bQ5dKz/w6wowMp6JN0/u+nmbZ1wKRpGpt9Mxm3HZ9lk5nA4rk1Mo8WQgOaQdM/vOWJ8zKpXFMJzMyaCMsXd2wxqNzZdG9a8Ki+zKtnxF7CGJRkmNi/t9UAqLduNcR3crrsSVG4xPpylQIfqrNaIiXJ9Ka+ds= 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)(376002)(136003)(39860400002)(396003)(346002)(366004)(451199015)(478600001)(110136005)(71200400001)(6506007)(9686003)(7696005)(316002)(26005)(166002)(45080400002)(786003)(41320700001)(64756008)(66946007)(38100700002)(66446008)(76116006)(66476007)(66556008)(40265005)(53546011)(5660300002)(8936002)(21615005)(41300700001)(52536014)(38070700005)(8676002)(186003)(66574015)(2906002)(33656002)(83380400001)(122000001)(55016003)(86362001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HZql5uGkTptrlFYRBZnnQLH4iF/nS2BbRqh152vc+yBWt9qHSOjbJxv3cr?= =?iso-8859-1?Q?35726Pn0DO3M5eGgerxocbONqCXRmLkouzHZ4g/9LWSFNFBrXI0CzKsZLV?= =?iso-8859-1?Q?9TRZ9ZtuSk2KEUKnGFXDCieW9bW79TGpOwzlklh2wGpu/yRF78fIqgjaON?= =?iso-8859-1?Q?G03bePvruYNPhEryOvKe6eBIC+KcCnr/U05ClholRRg0wFVLScyfJridOi?= =?iso-8859-1?Q?denvnArrmoo5M/fbPPduRXF/q2FDvC865PLxaVgHyY1Dk3hdBE4UbKI2Jw?= =?iso-8859-1?Q?tkRlEdEw8jXrYwZ1dKpD3RwUPvDxKaIw8syHASjyRLYpoZlvbGheX24ufj?= =?iso-8859-1?Q?5X9iIJro1dX77ARVcEI9sQ9FuFRdbVH+TJ9olx438LDzX0+mpr6GnnwUzr?= =?iso-8859-1?Q?Zt3J3uXsco0L/fLS9DZXHlB0IzuXk6XvsOvbNC/Om89XCo3DVOe0IQ+Ncb?= =?iso-8859-1?Q?qQD+EOh87SPUmjbM0j2XKmsU7UndPsxAwvoIYQKEOuj8CszMuXUs2G5D/p?= =?iso-8859-1?Q?KB1d+obHqjaVvq9o6DBYjPlaO3nq6hNzRFFDNcgH9nTQ4lX30XsTsj8h6W?= =?iso-8859-1?Q?tK+diqb4JJ0vM8/YgH255hADMX2AcQ7I6vkk+Iv04f6crLDqOwHwBlUz8g?= =?iso-8859-1?Q?URn7QTdcKabW7gdCVD7Mf/R1zTB8CrRgkjcm+z+P7LACl/LWP0vbL/03gt?= =?iso-8859-1?Q?41RNpf+lIVL/fx9cZpj7O6mCMn9DlwTESHrHMYmi0QEjZiGGjO3gS3rOkq?= =?iso-8859-1?Q?feu2rg0stM/Gg/CQKBW97TuI9nGhy1EEaBIurC5c4896HvF2raOyjcxXxo?= =?iso-8859-1?Q?4SA03Mr9pi6S5bGx+2Nx6/peN1EuuqdHuiswU4RYGhaeFMAzoyDdq/JIJW?= =?iso-8859-1?Q?9UyH+++LNuKSN9ChmYnuRmrqbeJR0gKgCOWUGkEXZl7rjAqYE//Z7oFB2U?= =?iso-8859-1?Q?SZFJufR5QTcM9aYiu88mItGYyNjFPoN29zz79pdLWuPHjjv5o2RUQsnSEo?= =?iso-8859-1?Q?iXbNsU5BiTcMPIJwr+Mgk9gxg26nwxkrrq4VTbZ7bcToz3rdx6cMiNBMQ5?= =?iso-8859-1?Q?BkF+oCLg8vTQD5CI6i3kOK95WmgORNkRjtI2Fa8XrSgkqcP23DxOJidZt+?= =?iso-8859-1?Q?sspN0m9w7zrDCuQRKJ2mzfd/aFDJhrE44fbPhG5Wz1idUGp64OdpBRPjH+?= =?iso-8859-1?Q?NEPZ+/35/ttDwpq4fiVgBv7cpICXdmJLqc4CM+hhYX4JZA7f6cPafe5jgV?= =?iso-8859-1?Q?WMCHV4QJHo7hEVzb0yIkNEAanmGsYYhDMsdmdHh6sdWGQ7g9PEajkHTVho?= =?iso-8859-1?Q?T5klBCx0yRSp7bOmW6LDJ0a4sD/s7cLSUFHWPNyleVVDIVHmvYpRyBcM/b?= =?iso-8859-1?Q?f73TuoYGNBK8kI9DarkCw5lDszzcWCjXzuYT8p4DqRj54zr63dg/yVeT29?= =?iso-8859-1?Q?vGeQtOVvCERNieGlPr+F61yaJMcIEpv31wm7yp0RejOTRZk1tr5wOFxvci?= =?iso-8859-1?Q?ILmiFS3D50PJ+Wbg/bH+9foqSv95jSkkuwXr27aj53rYQBvu/15T4JtzBS?= =?iso-8859-1?Q?/zNGyNQx0Kn7CgtSQ4HHbbdVc5yH60ukta28exNLM7duA8i+K6/sLkFUdy?= =?iso-8859-1?Q?gCTcZ5VJY1BJbtsCTnReyu8ElEk2OxBYTyy9PDdyXAVq3s3qXZ9wb6/g?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM0PR01MB56344D773BE9386629EED36DDD0E9AM0PR01MB5634eurp_" 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: d06c3b62-1c4d-4edb-3491-08dacf1a7027 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2022 19:22:48.3438 (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: k+Rn0OgHlN8gGBiaYwGdwyuqzYOfFniehLUVEoWZaWTvrsC9Lh5qRwrx+BWkygcPdwt+0njBSUjnh+Fu5EfsIm/6ff38Qj5hCheQ4Pm99Z0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR01MB8123 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_AM0PR01MB56344D773BE9386629EED36DDD0E9AM0PR01MB5634eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Okay, getting out of my comfort zone here. I have found encoding options for PostgreSQL (v15) here: PostgreSQL: Documentation: 15: 24.3. Character Set Support; they do not include UTF16, just UT= F8. There is no mention of UTF16 anywhere on that page. I also found this: PostgreSQL: Re: DataDirect Driver, ExecDirect and UTF-8<= https://www.postgresql.org/message-id/C631E68E.133%25ksell@greenplum.com> t= hat does mention WCHAR being different form CHAR and how that could work. I hope there is something on these pages that helps you further. Kind regards, Jan Tjalling From: Jon Raiford Sent: 25 November 2022 03:58 To: Wal, Jan Tjalling van der ; Marsupilami7= 9 ; pgsql-odbc@lists.postgresql.org Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte = count? I believe the point is that the function is a "W" (wide char 16-bit) functi= on so the strings should be UTF-16. Jon ________________________________ From: Wal, Jan Tjalling van der > Sent: Tuesday, November 22, 2022 11:21:56 AM To: Marsupilami79 >; pgsq= l-odbc@lists.postgresql.org > Subject: RE: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte = count? Hello Marsupilami79, Jan, It could be that the answers you receive are in fact correct for postgres. In a database set to charset=3DUTF-8 I get the following answers. select 'topsales' as string, char_length('topsales'), length('topsales'), = octet_length('topsales'); "string" "char_length" "length" "octet_length" "topsales" 8 8 8 However for a variation that requires more bytes to store the answer start = to differ. select 't=F6ps=E5l=E9s'as string, char_length('t=F6ps=E5l=E9s'), length('t= =F6ps=E5l=E9s'), octet_length('t=F6ps=E5l=E9s'); "string" "char_length" "length" "octet_length" "t=F6ps=E5l=E9s" 8 8 11 In the above octet_length is a postgres-function that yields results in byt= es. And the three characters with a diacritical added, each requires 2 bytes, y= ielding a resulting lengt of 11 instead of 8. Kind regards, Jan Tjalling van der Wal -----Original Message----- From: Marsupilami79 > Sent: 22 November 2022 16:57 To: pgsql-odbc@lists.postgresql.org Subject: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte coun= t? Hello, I am a co author of a data access library and we recently added an ODBC bri= dge. This bridge has the capability to detemine the current Catalog / Datab= ase. This is done by calling SQLGetConnectAttrW. We try to determine the size of the buffer that is needed for the catalog n= ame in the following manner: SQLGetConnectAttrW(fHDBC, SQL_ATTR_CURRENT_CATALOG, null, 0, &aLen) The ODBC driver for Microsoft SQL server correctly returns the number of by= tes required (10 bytes for the Database name "Stork") in the aLen parameter= . The ODBC driver for PostgreSQL returns the number of characters (8 charac= ters for a database named "topsales"), where it should return 16 for the nu= mber of bytes required. I tested this with the psqlodbc_13_02_0000-x86 download for Windows 10 and = installed the Unicode ODBC driver. I assume this is a bug and needs to be fixed. I just don't know if this is = the right place to report the bug to? With best regards, Jan --_000_AM0PR01MB56344D773BE9386629EED36DDD0E9AM0PR01MB5634eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Okay, gett= ing out of my comfort zone here.

I have fou= nd encoding options for PostgreSQL (v15) here:

PostgreSQL: Documentation: 15: 24.3. Character Set Supp= ort; they do not include UTF16, just UTF8.

There is n= o mention of UTF16 anywhere on that page.

 

I also fou= nd this: PostgreSQL: Re: DataDirect Driver, ExecDirect and UTF-8 that does mention WCHAR being different form CHAR and how that could work.<= o:p>

 = ;

I hope the= re is something on these pages that helps you further.

 = ;

Kind regar= ds, Jan Tjalling

 = ;

From: Jon Raiford <raiford@labware.com>
Sent: 25 November 2022 03:58
To: Wal, Jan Tjalling van der <jan_tjalling.vanderwal@wur.nl>;= Marsupilami79 <marsupilami79@gmx.de>; pgsql-odbc@lists.postgresql.or= g
Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> w= rong byte count?

 

I believe the point is that the function is a "= W" (wide char 16-bit) function so the strings should be UTF-16.

 

Jon

From: Wal, Jan Tjalling van der <jan_tjalling.vanderwal@wur.nl>
Sent: Tuesday, November 22, 2022 11:21:56 AM
To: Marsupilami79 <marsup= ilami79@gmx.de>; pgsql-odbc@lists.postgre= sql.org <pgsql-od= bc@lists.postgresql.org>
Subject: RE: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> w= rong byte count?

 

Hello Marsupilami79, = Jan,

It could be that the answers you receive are in fact correct for postgres.<= br> In a database set to charset=3DUTF-8 I get the following answers.

select  'topsales' as string, char_length('topsales'), length('topsale= s'), octet_length('topsales');
"string"         &nb= sp;      "char_length"   "= ;length"        "octet_length&= quot;
"topsales"      8    = ;           8  =              8<= br>
However for a variation that requires more bytes to store the answer start = to differ.
select  't=F6ps=E5l=E9s'as string, char_length('t=F6ps=E5l=E9s'), leng= th('t=F6ps=E5l=E9s'), octet_length('t=F6ps=E5l=E9s');
"string"         &nb= sp;      "char_length"   "= ;length"        "octet_length&= quot;
"t=F6ps=E5l=E9s"      8   = ;            8 =             &nb= sp; 11

In the above octet_length is a postgres-function that yields results in byt= es.
And the three characters with a diacritical added, each requires 2 bytes, y= ielding a resulting lengt of 11 instead of 8.

Kind regards, Jan Tjalling van der Wal


-----Original Message-----
From: Marsupilami79 <marsupilami= 79@gmx.de>
Sent: 22 November 2022 16:57
To: pgsql-odbc@lists.pos= tgresql.org
Subject: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte c= ount?

Hello,

I am a co author of a data access library and we recently added an ODBC bri= dge. This bridge has the capability to detemine the current Catalog / Datab= ase. This is done by calling SQLGetConnectAttrW.

We try to determine the size of the buffer that is needed for the catalog n= ame in the following manner:
SQLGetConnectAttrW(fHDBC, SQL_ATTR_CURRENT_CATALOG, null, 0, &aLen)

The ODBC driver for Microsoft SQL server correctly returns the number of by= tes required (10 bytes for the Database name "Stork") in the aLen= parameter. The ODBC driver for PostgreSQL returns the number of characters= (8 characters for a database named "topsales"), where it should return 16 for the number of bytes required.

I tested this with the psqlodbc_13_02_0000-x86 download for Windows 10 and = installed the Unicode ODBC driver.

I assume this is a bug and needs to be fixed. I just don't know if this is = the right place to report the bug to?

With best regards,

Jan

--_000_AM0PR01MB56344D773BE9386629EED36DDD0E9AM0PR01MB5634eurp_--