Re: handling unconvertible error messages - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: handling unconvertible error messages
Date
Msg-id 20160808.181154.252052789.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: handling unconvertible error messages  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: handling unconvertible error messages  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: handling unconvertible error messages  (Victor Wagner <vitus@wagner.pp.ru>)
List pgsql-hackers
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.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Next
From: Anastasia Lubennikova
Date:
Subject: Re: Refactoring of heapam code.