A piece :-) of code may be better than a piece of database vendor
related log data.
But creating a different output from mylog into a more general list of
calls would be a good starting point to create reusable code pieces -
in any language.
Cascaded code translators then would generate test snippets for an
This way, we would get many test snippets very fast. They must be
insertion into the test suite, but I think not more work than an
The idea to generate test descriptions from logfiles in general is
good. But the whole
system shouldn't related to pgSQLODBC only - in my opinion :-)
If you agree, then it should be designed more modular.
Such as input filters to translate vendor log data to a more general
APIXXX call log data.
Then we would not depend on the input. And ending with different output
I agree with Marc, to first have a look at the unixODBC test suite.
Ehhh, here is a (good - in my opinion) parsing generator tool:
In response to
pgsql-odbc by date
|Next:||From: noreply||Date: 2006-02-03 22:41:06|
|Subject: [ psqlodbc-Bugs-1000542 ] missing build instructions for unix|
|Previous:||From: Bruce Momjian||Date: 2006-02-03 12:49:10|
|Subject: Re: PostgreSQL Documentation Submission: MS Access and PostgreSQL |