Re: pl/perl and utf-8 in sql_ascii databases
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: pl/perl and utf-8 in sql_ascii databases |
Дата | |
Msg-id | 20120717.180110.152467693.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: pl/perl and utf-8 in sql_ascii databases (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: pl/perl and utf-8 in sql_ascii databases
|
Список | pgsql-hackers |
Hello, > > I suppose that testing for the two cases and additional > > one case which runs pg_do_encoding_conversion(), say latin1, > > would be enough to confirm that encoding/decoding is properly > > done, since the concrete conversion scheme is not significant > > this case. > > > > So I recommend that we should add the test for latin1 and omit > > the test from other than sql_ascii, utf8 and latin1. This might > > be archieved by create empty plperl_lc.sql and plperl_lc.out > > files for those encodings. > > > > What do you think about that? > > I think that's probably too much engineering for something that doesn't > really warrant it. A real solution to this problem could be to create > yet another new test file containing just this function definition and > the query that calls it, and have one expected file for each encoding; > but that's too much work and too many files, I'm afraid. I agree completely. The balance between the additional complexity of regress and the what we would get from the complexity... > I can see us supporting tests that require a small number of expected > files. No Make tricks with file copying, though. If we can't get > some easy way to test this without that, I submit we should just remove > the test. Ok I agree to do so. regards, -- Kyotaro Horiguchi NTT Open Source Software Center == My e-mail address has been changed since Apr. 1, 2012.
В списке pgsql-hackers по дате отправления: