Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vgh6U-0007uq-Ow for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Nov 2013 20:31:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vgh6U-0007nq-8W for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Nov 2013 20:31:58 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vgh6T-0007nT-5Z for pgsql-hackers@postgresql.org; Wed, 13 Nov 2013 20:31:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vgh6Q-0005ga-Ql; Wed, 13 Nov 2013 20:31:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id rADKVcBj024269; Wed, 13 Nov 2013 15:31:38 -0500 From: Tom Lane To: Martijn van Oosterhout cc: Tatsuo Ishii , maumau307@gmail.com, laurenz.albe@wien.gv.at, robertmhaas@gmail.com, peter_e@gmx.net, arul@fast.au.fujitsu.com, stark@mit.edu, Maksym.Boguk@au.fujitsu.com, hlinnakangas@vmware.com, pgsql-hackers@postgresql.org Subject: Re: UTF8 national character data type support WIP patch and list of open issues. In-reply-to: <20131113201950.GA800@svana.org> References: <7A2BD06B10A24EA4AA5FC5D93A70A754@maumau> <30151.1384101976@sss.pgh.pa.us> <20131112.155752.666523035722474275.t-ishii@sraoss.co.jp> <20131113201950.GA800@svana.org> Comments: In-reply-to Martijn van Oosterhout message dated "Wed, 13 Nov 2013 21:19:50 +0100" Date: Wed, 13 Nov 2013 15:31:38 -0500 Message-ID: <24268.1384374698@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Martijn van Oosterhout writes: > On Tue, Nov 12, 2013 at 03:57:52PM +0900, Tatsuo Ishii wrote: >> Once we implement the universal encoding, other problem such as >> "pg_database with multiple encoding problem" can be solved easily. > Isn't this essentially what the MULE internal encoding is? MULE is completely evil. It has N different encodings for the same character, not to mention no support code available. >> Currently there's no such an universal encoding in the universe, I >> think the only way is, inventing it by ourselves. > This sounds like a terrible idea. In the future people are only going > to want more advanced text functions, regular expressions, indexing and > making encodings that don't exist anywhere else seems like a way to > make a lot of work for little benefit. Agreed. > A better idea seems to me is to (if postgres is configured properly) > embed the non-round-trippable characters in the custom character part > of the unicode character set. In other words, adjust the mappings > tables on demand and voila.