From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |
Date: | 2018-10-11 21:11:47 |
Message-ID: | 24456.1539292307@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-10-11 21:53:10 | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |
Previous Message | Andres Freund | 2018-10-11 21:00:58 | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |