At Mon, 08 Aug 2016 18:11:54 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in
<20160808.181154.252052789.horiguchi.kyotaro@lab.ntt.co.jp>
> At Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote
in<20160808.171821.100221089.horiguchi.kyotaro@lab.ntt.co.jp>
> > Looking at check_client_encoding(), the comment says as following.
> >
> > | * If we are not within a transaction then PrepareClientEncoding will not
> > | * be able to look up the necessary conversion procs. If we are still
> > | * starting up, it will return "OK" anyway, and InitializeClientEncoding
> > | * will fix things once initialization is far enough along. After
> >
> > We shold overcome this to realize startup-time check for
> > conversion procs.
>
> Somewhat wrong. The core problem is the procedures offered by
> PrepareClientEncoding is choosed only by encoding->encoding
> basis, not counting character set compatibility. So, currently
> this is not detectable before actually doing conversion of a
> character stream.
>
> Conversely, providing a means to check character-set
> compatibility will naturally fixes this. Check at session-startup
> (out-of-transaction check?) is still another problem.
I don't see charset compatibility to be easily detectable,
because locale (or character set) is not a matter of PostgreSQL
(except for some encodings bound to one particular character
set)... So the conversion-fallback might be a only available
solution.
Thougts?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
