Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |
Дата | |
Msg-id | 9773.1539359331@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > On 10/12/2018 10:03 AM, Tom Lane wrote: >> Well, in any case I'd say we should put the dropping commands into >> a separate late-stage test script. Whether that's run by default is a >> secondary issue: if it is, somebody who wanted to test this stuff could >> remove the script from their test schedule file. > Anything that runs at the time we do the regression tests has problems, > from my POV. If we run the drop commands then upgrading these types to a > target <= 11 isn't tested. If we don't run them then upgrade to a > version > 11 will fail. This is why I suggested doing it later in the > buildfarm module that actaally does cross version upgrade testing. It > can drop or not drop prior to running the upgrade test, depending on the > target version. I'd like a solution that isn't impossibly difficult for manual testing of cross-version cases, too. That's why I'd like there to be a regression test script that does the necessary drops. Exactly when and how that gets invoked is certainly open for discussion. In the manual case I'd imagine calling it with EXTRA_TESTS while running the setup of the source database, if it's not run by default. Maybe the buildfarm module could just invoke the same script directly at a suitable point? regards, tom lane
В списке pgsql-hackers по дате отправления: