Re: pl/perl and utf-8 in sql_ascii databases
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: alvherre@commandprompt.com
Cc: tgl@sss.pgh.pa.us, badalex@gmail.com, cb@df7cb.de, pgsql-hackers@postgresql.org
Date: 2012-07-17T09:01:10Z
Lists: 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.