Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |
Дата | |
Msg-id | 20181011210058.4o54wspnwed24hwi@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel
|
Список | pgsql-hackers |
Hi, On 2018-10-11 16:57:02 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I've done that now, together with two commits for removal of timetravel > > and abstime, reltime, tinterval. > > Unsurprisingly-in-retrospect, buildfarm member crake is now bitching > that cross-version pg_upgrade fails, since it's trying to test importing > back-branch regression DBs that contain tables with the desupported types. > > Perhaps the best fix for this is to teach the cross-version-upgrade > buildfarm module to drop the affected tables from the old DB before > testing pg_upgrade. However, that does nothing to help manual testing > of similar scenarios. > > 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 :( Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: