At Mon, 08 Aug 2016 18:11:54 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20160808.181154.252052789.horiguchi.kyot...@lab.ntt.co.jp> > At Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote in > <20160808.171821.100221089.horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
