Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
От | Michael Paquier |
---|---|
Тема | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Дата | |
Msg-id | CAB7nPqS2RmpAxP=HHP=s_RYdpyRXVUUtT=+f0xxen4rm4GPmOQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Re: In-core regression tests for replication,
cascading, archiving, PITR, etc.
|
Список | pgsql-hackers |
On Wed, Dec 2, 2015 at 12:01 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Michael Paquier wrote: >> On Wed, Dec 2, 2015 at 8:11 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > >> > - It would be nice to have command_ok and command_fails in PostgresNode >> > too; that would remove the need for setting $ENV{PGPORT} but it's >> > possible to run commands outside a node too, so we'd need duplicates, >> > which would be worse. >> >> I am fine to let it the way your patch does it. There are already many changes. > > Idea: we can have a bare command_ok exported by TestLib just as > currently, and instance method PostgresNode->command_ok that first sets > local $ENV{PGPORT} and then calls the other one. Hm. That would be cleaner and make the code more consistent. Now as TestLib exports command_ok, command_like and command_fails, we would get redefinition errors when compiling the code if those routines are not named differently in PostgresNode. If you want to have the names consistent, then I guess that the only way would be to remove those routines from the export list of TestLib and call them directly as for example TestLib::command_ok(). See for example the patch attached that applies on top on your patch 2 that adds a set of routines in PostgresNode with a slightly different name. >> > Finally, I ran perltidy on all the files, which strangely changed stuff >> > that I didn't expect it to change. I wonder if this is related to the >> > perltidy version. Do you see further changes if you run perltidy on the >> > patched tree? >> >> SimpleTee.pm shows some diffs, though it doesn't seem that this patch >> should care about that. The rest is showing no diffs. And I have used >> perltidy v20140711. > > Yes, the patch doesn't modify SimpleTee -- I just used "find" to indent > perl files. What I don't understand is why doesn't my perltidy run > match what was in master currently. It should be a no-op ... Well I don't get it either :) I did a run on top of your two patches and saw no differences. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: