Re: Extracting cross-version-upgrade knowledge from buildfarm client
От | Tom Lane |
---|---|
Тема | Re: Extracting cross-version-upgrade knowledge from buildfarm client |
Дата | |
Msg-id | 1408423.1673798470@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Extracting cross-version-upgrade knowledge from buildfarm client (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Extracting cross-version-upgrade knowledge from buildfarm client
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > On 2023-01-14 Sa 15:06, Tom Lane wrote: >> Here's version 2, incorporating your suggestions and with some >> further work to make it handle 9.2 fully. > This looks pretty good to me. Great! I'll work on making back-branch versions. > I'll probably change this line > my $adjust_cmds = adjust_database_contents($oversion, %dbnames); > so it's only called if the old and new versions are different. Is there > any case where a repo shouldn't be upgradeable to its own version > without adjustment? Makes sense. I'd keep the check for $oversion eq 'HEAD' in the subroutines, but that's mostly just to protect the version conversion code below it. Another thing I was just thinking about was not bothering to run "diff" if the fixed dump strings are equal in-memory. You could take that even further and not write out the fixed files at all, but that seems like a bad idea for debuggability of the adjustment subroutines. However, I don't see why we need to write an empty diff file, nor parse it. One other question before I continue --- do the adjustment subroutines need to worry about Windows newlines in the strings? It's not clear to me whether Perl will automatically make "\n" in a pattern match "\r\n", or whether it's not a problem because something upstream will have stripped \r's. regards, tom lane
В списке pgsql-hackers по дате отправления: