Added option flag to exclude certain statements

[sdressler]

Great tool! As we are developing a PSQL DB plugin where certain statements are not supported, I wanted to exclude these. IMO my implementation is rather naive and I certainly can do better but I need to understand the code a bit more first. It currently focuses only on statements like UPDATE, DELETE, ...

I also took the liberty to switch the comparison to a lambda which increases maintainability IMO.

Potential improvements are:

• Restrict to only possible choices, and
• Change the lookup to a bitmask, haven't checked the impact on the query generation rate yet but I think it slows down.

[anse1]

Hi Sebastian, thanks for your patch. I'm unsure whether to merge it though, details below. Sebastian Dreßler writes:

Great tool! As we are developing a PSQL DB plugin where certain statements are not supported, I wanted to exclude these. IMO my implementation is rather naive and I certainly can do better but I need to understand the code a bit more first. It currently focuses only on statements like UPDATE, DELETE, ...

I originally intended the impedance matching code (impedance.cc) as a means to deal with unsupported output from sqlsmith. Statements - or any other productions of the grammar - that consistently lead to an error are automatically put on a blacklist. I'm afraid it doesn't work right-away with plain update or delete statements because the check whether the production was blacklisted is missing. So far, I only added this check to productions that are known not to be widely supported, such as UPDATE RETURNING or UPSERT (see the calls to match()). Currently, I have the impression that adding these calls to make the automatic blacklisting work for the statements unsupported by your extension is a more consistent solution, and the patch would be redundant then. Would this solution work for you?

I also took the liberty to switch the comparison to a lambda which increases maintainability IMO.

Yay :-)

- Change the lookup to a bitmask, haven't checked the impact on the query generation rate yet but I think it slows down.

Not needed: SQLsmith is spending most of the time constructing subtrees and then discarding them and backtracking because it cannot find a way to join it. A simple check at a top-level statement shouldn't be relevant in contrast. regards, Andreas