> > 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.
NTT Open Source Software Center
== My e-mail address has been changed since Apr. 1, 2012.
In response to
pgsql-hackers by date
|Next:||From: Samuel Vogel||Date: 2012-07-17 09:34:34|
|Subject: Re: b-tree index search algorithms|
|Previous:||From: Daniel Farina||Date: 2012-07-17 08:02:09|
|Subject: Re: Using pg_upgrade on log-shipping standby servers|