David Fetter writes:
> On Mon, Dec 14, 2015 at 03:06:18PM +0900, Michael Paquier wrote:
>> On Sun, Dec 13, 2015 at 10:14 AM, Andreas Seltenreich wrote:
>> > https://github.com/anse1/sqlsmith
>>
>> I am in awe regarding this stuff, which has caught many bugs
>> already, it is a bit sad that it is released under the GPL license
>> preventing a potential integration into PostgreSQL core to
>> strengthen the test infrastructure,
>
> I suspect that a polite request to the Andreas that he change to a
> PostgreSQL-compatible license like one of (TPL, BSD2, MIT) might
> handle this part.
It probably would, but I never thought core integration would be a
desirable thing. Like Csmith, SQLsmith is intended to be
product-agnostic. That's not yet the case, but it's still on the
roadmap.
Further, the license shouldn't interfere with institutionalizing
sqlsmith somewhere to automatically send mails on failed assertions or
first sight of an error message. Or providing a web interface around
the logging database of an instance where one can drill down on logged
errors/queries.
>> and it is even sadder to see a direct dependency with libpqxx :(
>
> I suspect this part is a SMOP, but I'm not quite sure what S might
> constitute in this case.
sqlsmith uses three connections in total:
1. Connection for sending the generated queries to the DUT2. Connection for retrieving the schema from the DUT3.
Loggingconnection
1 is trivial to change. 1+2 are intendend to be pluggable for supporting
other products. Switching 1 to libpq is even on the todo list, as
libpqxx doesn't allow access to the SQLSTATE (There is a four year old
bug report about this by Andres).
2. Is more effort to change to libpq, as actual data is passed through
that connection.
3. Was intended to stay libpqxx-only even when testing other products.
Btw, I'm glad C++11 was no longer considered a blocker this thime :-)
regards,
Andreas