mirror of
https://github.com/postgres/postgres.git
synced 2026-02-27 03:40:28 -05:00
2dfa15de55
This test previously used a data value containing U+0080, and would therefore fail if the database encoding didn't have an equivalent to that; which only about half of our supported server encodings do. We could fall back to using some plain-ASCII character, but that seems like it's losing most of the point of the test. Instead switch to using U+00A0 (no-break space), which translates into all our supported encodings except the four in the EUC_xx family. Per buildfarm testing. Back-patch to 9.1, which is as far back as this test is expected to succeed everywhere. (9.0 has the test, but without back-patching some 9.1 code changes we could not expect to get consistent results across platforms anyway.) |
||
|---|---|---|
| .. | ||
| plpython_composite.out | ||
| plpython_do.out | ||
| plpython_drop.out | ||
| plpython_error.out | ||
| plpython_error_0.out | ||
| plpython_global.out | ||
| plpython_import.out | ||
| plpython_newline.out | ||
| plpython_params.out | ||
| plpython_populate.out | ||
| plpython_quote.out | ||
| plpython_record.out | ||
| plpython_schema.out | ||
| plpython_setof.out | ||
| plpython_spi.out | ||
| plpython_subtransaction.out | ||
| plpython_subtransaction_0.out | ||
| plpython_subtransaction_5.out | ||
| plpython_test.out | ||
| plpython_trigger.out | ||
| plpython_types.out | ||
| plpython_types_3.out | ||
| plpython_unicode.out | ||
| plpython_void.out | ||
| README | ||
Guide to alternative expected files: plpython_error_0.out Python 2.4 and older plpython_unicode.out server encoding != SQL_ASCII plpython_unicode_3.out server encoding == SQL_ASCII plpython_subtransaction_0.out Python 2.4 and older (without with statement) plpython_subtransaction_5.out Python 2.5 (without with statement) plpython_types_3.out Python 3.x