Re: Test to dump and restore objects left behind by regression
От | Alvaro Herrera |
---|---|
Тема | Re: Test to dump and restore objects left behind by regression |
Дата | |
Msg-id | 202502060943.ll3pmkzj3zm2@alvherre.pgsql обсуждение исходный текст |
Ответ на | Test to dump and restore objects left behind by regression (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Список | pgsql-hackers |
On 2025-Feb-06, Michael Paquier wrote: > On Wed, Feb 05, 2025 at 03:28:04PM +0900, Michael Paquier wrote: > > Hmm. I was reading through the patch and there is something that > > clearly stands out IMO: the new compare_dumps(). It is in Utils.pm, > > and it acts as a wrapper of `diff` with its formalized output format. > > It is not really about dumps, but about file comparisons. This should > > be renamed compare_files(), with internals adjusted as such, and > > reused in all the existing tests. Good idea to use that in > > 027_stream_regress.pl, actually. I'll go extract that first, to > > reduce the presence of `diff` in the whole set of TAP tests. > > The result of this part is pretty neat, resulting in 0001 where it is > possible to use the refactored routine as well in pg_combinebackup > where there is a piece comparing dumps. There are three more tests > with diff commands and assumptions of their own, that I've left out. Great, I've looked at doing something like this in the libpq_pipeline test for better diff reporting -- what I have uses Test::Differences, which is pretty neat and usable, but it's not part of the standard installed perl modules, which is a large downside. I can probably get rid of my hack once you get 0001 in. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge)
В списке pgsql-hackers по дате отправления: