Hello,
Advertising
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
PostgresNode.
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.
Ok.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
