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 1r3d2V-004peV-76 for pgsql-bugs@arkaria.postgresql.org; Thu, 16 Nov 2023 14:08:15 +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 1r3d2T-007FQG-0V for pgsql-bugs@arkaria.postgresql.org; Thu, 16 Nov 2023 14:08:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r3d2S-007FPp-Nm for pgsql-bugs@lists.postgresql.org; Thu, 16 Nov 2023 14:08:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r3d2Q-005rtx-6i for pgsql-bugs@lists.postgresql.org; Thu, 16 Nov 2023 14:08:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3AGE88GK215795; Thu, 16 Nov 2023 09:08:08 -0500 From: Tom Lane To: "Daniel Verite" cc: halilhanbadem@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18196: Databases Created in Turkish Language Will Not Run on the Latest Version of Windows In-reply-to: <48b32b36-1356-43f4-919b-a70dee481304@manitou-mail.org> References: <48b32b36-1356-43f4-919b-a70dee481304@manitou-mail.org> Comments: In-reply-to "Daniel Verite" message dated "Thu, 16 Nov 2023 13:58:24 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <215793.1700143688.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Thu, 16 Nov 2023 09:08:08 -0500 Message-ID: <215794.1700143688@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Daniel Verite" writes: > Aside from the disappearance of the previous name, this "ü" in the new > name also looks troublesome. It might be encoded as a single byte in > an encoding of the ISO-8859-* family, in which case the byte would be > 0xFC it seems, but in an UTF-8 context, it would be represented by the > sequence 0xC3 0xBC. Indeed. That jogged my memory that we've dealt with this sort of thing before; search the commit log for mentions of "Norwegian (Bokmål)". I guess we could add mapping entry(s) similar to what we use for that, although that won't help anybody who's already stuck with an unstartable database. regards, tom lane