Re: Encoding problems in PostgreSQL with XML data

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: hannu(at)tm(dot)ee
Cc: merlin(dot)moncure(at)rcsonline(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Encoding problems in PostgreSQL with XML data
Date: 2004-01-21 04:51:52
Message-ID: 20040121.135152.59650067.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 :)

We need this because our parser cannot handle some encodings including
UCS, Shift-JIS and Big5 (we currently do not allow UCS as a client
side encoding, but this is another story).

> 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.

IMO this does not help our parser's limitation neither.

> 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex 2004-01-21 05:25:23 Re: SQL Exception Relation xxx does not exist
Previous Message Christopher Kings-Lynne 2004-01-21 01:35:02 Re: [Fwd: plpgsql and booleans?]