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 1qWSwB-003LdF-I0 for pgsql-admin@arkaria.postgresql.org; Thu, 17 Aug 2023 02:40:39 +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 1qWSwA-00CGBf-7t for pgsql-admin@arkaria.postgresql.org; Thu, 17 Aug 2023 02:40:38 +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 1qWSw9-00CGBV-Rj for pgsql-admin@lists.postgresql.org; Thu, 17 Aug 2023 02:40:37 +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 1qWSw6-000Y2I-HU for pgsql-admin@lists.postgresql.org; Thu, 17 Aug 2023 02:40:36 +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 37H2eWdw1727536; Wed, 16 Aug 2023 22:40:32 -0400 From: Tom Lane To: "James Pang (chaolpan)" cc: "pgsql-admin@lists.postgresql.org" Subject: Re: inserts bypass encoding conversion In-reply-to: References: <1320633.1692194575@sss.pgh.pa.us> <1717988.1692235980@sss.pgh.pa.us> Comments: In-reply-to "James Pang (chaolpan)" message dated "Thu, 17 Aug 2023 02:25:57 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1727534.1692240032.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2023 22:40:32 -0400 Message-ID: <1727535.1692240032@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "James Pang (chaolpan)" writes: > So, insert into values(chr(226)||chr(128)||chr(166)) actually got store= d in database with LATIN1 with single byte sequence, but when query select= * from testutf8, it got converted to UTF8 three byte sequence first ? = There are no LATIN1 characters that have longer than 2-byte UTF8 representations, so no. I think your fundamental misunderstanding is supposing that this: chr(226)||chr(128)||chr(166) produces something equivalent to the UTF8 sequence 0xe2 0x80 0xa6. It will not, no matter which server encoding you are dealing with. It will produce something that is three separate characters according to the server encoding. In LATIN1, that could well be the byte sequence 0xe2 0x80 0xa6, but *that byte sequence does not mean the same thing that it would mean in UTF8 encoding*. You also seem not to grasp the fact that an encoding conversion will happen between your client and the server if client_encoding is different from server_encoding. Because of that, the output of a SELECT command doesn't prove much of anything here. regards, tom lane