SQL test backfilling

[seebs]

This is actually two related sets of test cases in the parser/scanner stuff. (tickets 2073, 2074)

There's a couple of things in here which may want more careful attention. One is the previously-commented-out test case for a double inner join. It was commented out because stringizing the resulting data structure produced wildly different output, which broke the basic sanity checks. After studying this a bit, I've concluded that the code to "rewrite last source to nest next join on right side" logic was, in fact, precisely backwards -- we simply didn't want that code at all. Taking it out and expecting a data structure that makes sense also produces a data structure which stringizes back to the original query.

We add support for StringLit to know whether they came from blobs or not, so they can stringize to blobs again, so the round-trip testing works with them.

We add a test case that tests tuple assignment. I note that tuple assignment looks weird -- you have to use {} for the values, but () for the column names.

There's a number of still-unreached cases, but most of them are things where we check a token type with peek to decide to call a function, then that function asserts that the next token is that type. This shouldn't be capable of failing, but it's not a bad idea to have the extra checking there, I think?

[seebs]

Tagged Pat because the double-join logic wants someone who understands SQL to look at it more closely.

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication