> 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.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
