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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
