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
