On Sat, Jan 14, 2023 at 03:06:06PM -0500, Tom Lane wrote: > I tried to use this to replace upgrade_adapt.sql, but failed so > far because I couldn't figure out exactly how you're supposed > to use 002_pg_upgrade.pl with an old source installation. > It's not terribly well documented.
As in pg_upgrade's TESTING or the comments of the tests? > In any case I think we > need a bit more thought about that, because it looks like > 002_pg_upgrade.pl thinks that you can supply any random dump > file to serve as the initial state of the old installation; > but neither what I have here nor any likely contents of > upgrade_adapt.sql or the "custom filter" rules are going to > work on databases that aren't just the standard regression > database(s) of the old version. Yeah, this code needs an extra push that I have not been able to figure out yet, as we could recommend the creation of a dump with installcheck-world and USE_MODULE_DB=1. Perhaps a module is just better at the end. > I assume we should plan on reverting 9814ff550 (Add custom filtering > rules to the TAP tests of pg_upgrade)? Does that have any > plausible use that's not superseded by this patchset? Nope, this could just be removed if we finish by adding a module that does exactly the same work. If you are planning on committing the module you have, i'd be happy to take care of a revert for this part. + # 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. Is this module pluggable with 002_pg_upgrade.pl? -- Michael
signature.asc
Description: PGP signature