Re: Test to dump and restore objects left behind by regression
От | Michael Paquier |
---|---|
Тема | Re: Test to dump and restore objects left behind by regression |
Дата | |
Msg-id | ZmD2xoIa2-MJqMGs@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Test to dump and restore objects left behind by regression (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: Test to dump and restore objects left behind by regression
|
Список | pgsql-hackers |
On Wed, Jun 05, 2024 at 05:09:58PM +0530, Ashutosh Bapat wrote: > Thanks for the suggestion. I didn't understand the dependency with the > buildfarm module. Will the new module be used in buildfarm separately? I > will work on this soon. Thanks for changing CF entry to WoA. I had some doubts about PGBuild/Modules/TestUpgradeXversion.pm, but after double-checking it loads dynamically AdjustUpgrade from the core tree based on the base path where all the modules are: # load helper module from source tree unshift(@INC, "$srcdir/src/test/perl"); require PostgreSQL::Test::AdjustUpgrade; PostgreSQL::Test::AdjustUpgrade->import; shift(@INC); It would be annoying to tweak the buildfarm code more to have a different behavior depending on the branch of Postgres tested. Anyway, from what I can see, you could create a new module with the dump filtering rules that AdjustUpgrade requires without having to update the buildfarm code. > Changing the physical order of column of a child table based on the > inherited table seems intentional as per MergeAttributes(). That logic > looks sane by itself. In binary mode pg_dump works very hard to retain the > column order by issuing UPDATE commands against catalog tables. I don't > think mimicking that behaviour is the right choice for non-binary dump. I > agree with your conclusion that we fix it in by fixing the diffs. The code > to do that will be part of a separate module. Thanks. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: