Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Дата
Msg-id 24456.1539292307@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Список pgsql-hackers
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.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel