mirror of
https://github.com/postgres/postgres.git
synced 2026-02-14 08:13:27 -05:00
8a19c1a373
Although the documentation for append_conf said clearly that it didn't add a newline, many test authors seem to have forgotten that ... or maybe they just consulted the example at the top of the POD documentation, which clearly shows adding a config entry without bothering to add a trailing newline. The worst part of that is that it works, as long as you don't do it more than once, since the backend isn't picky about whether config files end with newlines. So there's not a strong forcing function reminding test authors not to do it like that. Upshot is that this is a terribly fragile way to go about things, and there's at least one existing test case that is demonstrably broken and not testing what it thinks it is. Let's just make append_conf append a newline, instead; that is clearly way safer than the old definition. I also cleaned up a few call sites that were unnecessarily ugly. (I left things alone in places where it's plausible that additional config lines would need to be added someday.) Back-patch the change in append_conf itself to 9.6 where it was added, as having a definitional inconsistency between branches would obviously be pretty hazardous for back-patching TAP tests. The other changes are just cosmetic and don't need to be back-patched. Discussion: https://postgr.es/m/19751.1492892376@sss.pgh.pa.us |
||
|---|---|---|
| .. | ||
| brin | ||
| commit_ts | ||
| dummy_seclabel | ||
| snapshot_too_old | ||
| test_ddl_deparse | ||
| test_extensions | ||
| test_parser | ||
| test_pg_dump | ||
| test_rls_hooks | ||
| test_shm_mq | ||
| worker_spi | ||
| Makefile | ||
| README | ||
Test extensions and libraries ============================= src/test/modules contains PostgreSQL extensions that are primarily or entirely intended for testing PostgreSQL and/or to serve as example code. The extensions here aren't intended to be installed in a production server and aren't suitable for "real work". Most extensions have their own pg_regress tests or isolationtester specs. Some are also used by tests elsewhere in the tree. If you're adding new hooks or other functionality exposed as C-level API this is where to add the tests for it.