From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:00:58 |
Message-ID: | 20181011210058.4o54wspnwed24hwi@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-10-11 16:57:02 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-10-11 21:11:47 | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |
Previous Message | Tom Lane | 2018-10-11 20:57:02 | Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel |