> > 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.


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:

Reply via email to