Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org, Andrew Dunstan <andrew@dunslane.net>
Date: 2018-10-11T21:53:10Z
Lists: pgsql-hackers
Hi, On 2018-10-11 17:11:47 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2018-10-11 16:57:02 -0400, Tom Lane wrote: > >> Another idea would be to put table drops into the back branch regression > >> tests, so that their ending states don't include any such tables. That > >> would cripple pg_dump testing of these types in the back branches, but > >> I'm not sure if we really care much. > > > I think the latter is the better choice. Given the code for those types > > hasn't changed meaningfully in the last decade, I think not having > > pg_dump coverage would be ok. > > >> I don't especially like either of these choices --- anyone got another > >> idea? > > > Nope :( > > A compromise that occurred to me after a bit of reflection is to place > the necessary table-drop commands in a new regression test script that's > meant to be executed last, but isn't actually run by default. Then > teach the cross-version-update test script to include that script via > EXTRA_TESTS. Manual testing could do likewise. Then we have a small > amount of pain for testing upgrades, but we lose no test coverage in > back branches. To me that seems to be more work / infrastructure than warranted. abstime/reltime/tinterval don't present pg_dump with any special challenges compared to a lot of other types we do test, no? Greetings, Andres Freund
Commits
-
Clean up/tighten up coercibility checks in opr_sanity regression test.
- e9f42d529f99 12.0 landed
-
Remove abstime, reltime, tinterval tables from old regression databases.
- fb583c80d230 9.3.25 landed
- 7b88c1ddd049 9.4.20 landed
- 9320263ae7ca 10.6 landed
- 43cc4e49edff 9.5.15 landed
- 2ad422ce10a4 9.6.11 landed
- 184951a48a10 11.0 landed