X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 9B0AAD1DB08 for ; Tue, 13 Jan 2004 12:43:21 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 19445-05 for ; Tue, 13 Jan 2004 08:42:53 -0400 (AST) Received: from fuji.krosing.net (silmet.estpak.ee [194.126.97.78]) by svr1.postgresql.org (Postfix) with ESMTP id DDC3ED1DA9F for ; Tue, 13 Jan 2004 08:42:43 -0400 (AST) Received: from fuji.krosing.net (localhost.localdomain [127.0.0.1]) by fuji.krosing.net (8.12.8/8.12.8) with ESMTP id i0DCggnj002622; Tue, 13 Jan 2004 14:42:42 +0200 Received: (from hannu@localhost) by fuji.krosing.net (8.12.8/8.12.8/Submit) id i0DCgfKF002620; Tue, 13 Jan 2004 14:42:41 +0200 X-Authentication-Warning: fuji.krosing.net: hannu set sender to hannu@tm.ee using -f Subject: Re: Encoding problems in PostgreSQL with XML data From: Hannu Krosing To: Merlin Moncure Cc: pgsql-hackers@postgresql.org In-Reply-To: <303E00EBDD07B943924382E153890E5434AA4F@cuthbert.rcsinc.local> References: <303E00EBDD07B943924382E153890E5434AA4F@cuthbert.rcsinc.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1073997761.2528.8.camel@fuji.krosing.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 13 Jan 2004 14:42:41 +0200 X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200401/290 X-Sequence-Number: 49014 Merlin Moncure kirjutas E, 12.01.2004 kell 19:56: > Hannu Krosing wrote: > > IIRC, the charset transformations are done as a separate step in the > > wire protocol _before_ any parser has chance transform or not. > > Yep. My point is that this is wrong. Of course :) It seems to be a quick hack somebody implemented in need, and doing it as a separate step was suely the easiest way to get it working. I hope that real as-needed-column-by-column translation will be used with bound argument queries. It also seems possible to delegate the encoding changes to after the query is parsed, but this will never work for EBCDIC and other funny encodings (like rot13 ;). for these we need to define the actual SQL statement encoding on-wire to be always ASCII. --------------- Hannu