From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extracting cross-version-upgrade knowledge from buildfarm client |
Date: | 2023-01-15 23:02:07 |
Message-ID: | 1746620.1673823727@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Sat, Jan 14, 2023 at 03:06:06PM -0500, Tom Lane wrote:
> + # Can't upgrade aclitem in user tables from pre 16 to 16+.
> + _add_st($result, 'regression',
> + 'alter table public.tab_core_types drop column aclitem');
> Could you just use a DO block here to detect tables with such
> attributes, like in upgrade_adapt.sql, rather than dropping the table
> from the core tests? That's more consistent with the treatment of
> WITH OIDS.
I guess, but it seems like make-work as long as there's just the one
column.
> Is this module pluggable with 002_pg_upgrade.pl?
I did find that 002_pg_upgrade.pl could load it. I got stuck at
the point of trying to test things, because I didn't understand
what the test process is supposed to be for an upgrade from a
back branch. For some reason I thought that 002_pg_upgrade.pl
could automatically create the old regression database, but
now I see that's not implemented.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-15 23:03:20 | Re: The documentation for storage type 'plain' actually allows single byte header |
Previous Message | Michael Paquier | 2023-01-15 22:51:07 | Re: Extracting cross-version-upgrade knowledge from buildfarm client |