Nope. TestLib does not know about PostgresNode, the idea is rather that
PostgresNode knows and wraps around TestLib when needed.

Actually as I look at this part, I feeling an urge to rewrite this code, and
change it so, that all command_like calls were called in a context of certain
node, but it is subject for another patch. In this patch it would be good to
use TestLib functions as they are now, or with minimum modifications.

I do not understand. In the v2 I sent ISTM that I did exactly as it is done for other test functions:

 - the test function itself is in TestLib

 - PostgresNode wraps around it to provide the necessary connection
   information which it is holding.

Maybe a better pattern could be thought of, but at least now my addition is consistent with pre-existing code.

Now I can add a command_likes which allows to manage status, stdout and
stderr and add that in TestLib & PostgresNode.

This is good idea too, I still do not understand why do you want to add it to

There is a command_like function in TestLib and a method of the same name in PostgresNode to provide the function with connections informations.

And name command_likes -- a very bad solution, as it can easily be confused
with command_like.

That is a good point. What other name do you suggest?

If it is possible to do it backward compatible, I would try
to improve command_like, so it can check all the results. If it is not, I
would give this function a name that brings no confusion.

The problem I have with the pre-existing functions is that they do a partial job: whether status is ok nor not, whether stdout contains something XOR whether stderr contains something. I want to do all that repeatedly, hence the enhanced version which checks all three with list of patterns.

Now maybe I can extend the existing "command_like" to check for extra arguments, to get the expected status and manage list of patterns for both stdout & stderr instead of a single regex, but for me this is somehow a distinct function.

Hmmm. I thought of that but was very unconvinced by the approach: pgbench basically always requires a file, so what the stuff was doing was writting the script into a file, checking for possible errors when doing so, then unlinking the file and checking for errors again after the run.

I think I was wrong about deleting file after tests are finished. Better
keep them.

Hmmm... Then what is the point not to have them as files to begin with?

Not to have them in source code tree in git.

I do not see that as a problem, the point of git is to manage file contents anyway.

Now, as I said, I will write unreadable code if required, I will only be sad about it.

The rest would be in the answer to another sum up letter.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to