Pursuant to today's discussion at PGCon about code coverage, I went
nosing into some of the particularly under-covered subdirectories
in our tree, and immediately tripped over an interesting factoid:
the ASCII<->MIC and ASCII<->UTF8 encoding conversion functions are
untested ... not because the regression tests don't try, but because
those conversions are unreachable. pg_do_encoding_conversion() and
its sister functions have hard-wired fast paths for any conversion
in which the source or target encoding is SQL_ASCII, so that an
encoding conversion function declared for such a case will never
be used.
(The coverage results do show ascii_to_utf8 as being covered, but
that's just because alter_table.sql randomly chose to test
ALTER CONVERSION using a user-defined conversion from SQL_ASCII
to UTF8, rather than any other case. CreateConversionCommand()
will invoke the specified function on an empty string just to see
if it works, so that's where that "coverage" comes from.)
This situation seems kinda silly. My inclination is to delete
these functions as useless, but I suppose another approach is
to suppress the fast paths if there's a declared conversion function.
(Doing so would likely require added catalog lookups in places we
might not want them...)
If we do delete them as useless, it might also be advisable to change
CreateConversionCommand() to refuse creation of conversions to/from
SQL_ASCII, to prevent future confusion.
Thoughts?
regards, tom lane
