Greg Stark <st...@mit.edu> writes: > Not sure what other encodings you mean. Psql uses utf8 for the border and > the test uses utf8 to test the formatting. I was only anticipating an error > on platforms where that didn't work.
Well, there are two likely misbehaviors if the regression test is being run in some other encoding: 1. If it's a single-byte encoding, you probably won't get any bad-encoding complaints, but the code will think the utf8 characters represent multiple logical characters, resulting in (at least) spacing differences. It's possible that all single-byte encodings would act the same, but I'm not sure. 2. If it's a multi-byte encoding different from utf8, you're almost certainly going to get badly-encoded-data complaints, at different places depending on the particular encoding. I don't remember how many different multibyte encodings we support, but I'm pretty sure we'd need a separate expected file for each one. Plus at least one for the single-byters. The real problem is that I don't have a lot of confidence that the buildfarm would provide us with full coverage of all the encodings that somebody might use in the field. So we might not find out about omissions or wrong expected-files until after we ship. Anyway, the bottom line for me is that this test isn't worth that much trouble. I'm okay with putting it in as a separate test file that we don't support running in non-utf8 encodings. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers