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.
