Thread: In which good intentions are punished, take 2
Since I committed 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 to make pg_do_encoding_conversion not fail silently, buildfarm member magpie has been whining: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=magpie&dt=2014-02-25%2011%3A00%3A08 To wit, that if you run contrib/citext's regression tests in a LATIN2-encoded database, you get this: SELECT convert_to( name, 'ISO-8859-1' ) = convert_to( name::text, 'ISO-8859-1' ) AS t FROM srt; ! ERROR: default conversion function for encoding "LATIN2" to "LATIN1" does not exist Well, it's right, there is no such conversion function. A quick look in the buildfarm logs for older runs confirms that previously, all we were getting was the useless LOG bleats that the previous coding emitted: LOG: default conversion function for encoding "LATIN2" to "LATIN1" does not exist STATEMENT: SELECT convert_to( name, 'ISO-8859-1' ) = convert_to( name::text, 'ISO-8859-1' ) AS t FROM srt; That didn't appear in the user-visible output, allowing the regression test to appear to "pass" although under no circumstances could it be argued that what was happening was sane. We could possibly replace this test case with SELECT convert_from( name::bytea, 'SQL_ASCII' ) = convert_from( name::text::bytea, 'SQL_ASCII' ) AS t FROM srt; though I'm not sure I see the point: whatever you might think this statement is testing, it's not got much to do with citext. On the other hand, we evidently have got precious little other buildfarm coverage of the convert() family of functions, so maybe removing this test altogether wouldn't be the best thing either. Thoughts? regards, tom lane
Tom Lane wrote: > On the > other hand, we evidently have got precious little other buildfarm > coverage of the convert() family of functions, so maybe removing > this test altogether wouldn't be the best thing either. We do have precious little testing on encodings and conversions, yes. The problem is how to test these things without having the tests fail when any particular encoding is not installed in the test system. Maybe we can use the Perl test rig for this too: Peter said that if a test requires something not installed, the test is skipped without causing a failure. It seems to me that we could take advantage that so that each member tests whatever involves only the encodings it has installed; while each individual member would skip a large percentage of tests, the buildfarm as a whole would be testing a sizable portion, if not all of it. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 02/25/2014 08:53 PM, Alvaro Herrera wrote: > Tom Lane wrote: > >> On the >> other hand, we evidently have got precious little other buildfarm >> coverage of the convert() family of functions, so maybe removing >> this test altogether wouldn't be the best thing either. > We do have precious little testing on encodings and conversions, yes. > The problem is how to test these things without having the tests fail > when any particular encoding is not installed in the test system. > > Maybe we can use the Perl test rig for this too: Peter said that if a > test requires something not installed, the test is skipped without > causing a failure. It seems to me that we could take advantage that so > that each member tests whatever involves only the encodings it has > installed; while each individual member would skip a large percentage of > tests, the buildfarm as a whole would be testing a sizable portion, if > not all of it. > It should be easy (at least on *nix) for the buildfarm client to check what encodings are installed on the machine and run tests accordingly. I haven't been following closely, but if someone provides me with a simple spec I'll try to code it up. We're about due for a release anyway. cheers andrew