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