fix: extract tables doesn't work with reserved keywords

[betodealmeida]

SUMMARY

I decided to convert some integration tests to unit tests. The low hanging fruit for this are the sqlparse tests, since they're self contained, so I decided to start there.

As soon as I created my first test, I found a bug. I changed the SQL:

SELECT * FROM tbname

To:

SELECT * FROM table_name

And the test failed to identify table_name as a table in the query, since it's a reserved word in sqlparse.

I fixed the problem, and converted all the integration tests.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N/A

TESTING INSTRUCTIONS

Added unit tests covering the problem.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

Merging #17654 (bccf8b9) into master (8e02d11) will increase coverage by 0.18%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #17654      +/-   ##
==========================================
+ Coverage   68.66%   68.85%   +0.18%     
==========================================
  Files        1596     1597       +1     
  Lines       65224    65291      +67     
  Branches     6950     6950              
==========================================
+ Hits        44789    44957     +168     
+ Misses      18550    18449     -101     
  Partials     1885     1885              

Flag	Coverage Δ
hive	81.40% <100.00%> (?)
javascript	57.45% <ø> (ø)
mysql	82.09% <100.00%> (+0.28%)	⬆️
postgres	82.10% <100.00%> (+0.28%)	⬆️
presto	?
python	82.45% <100.00%> (+0.37%)	⬆️
sqlite	81.79% <100.00%> (+0.28%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset/sql_parse.py	99.44% <100.00%> (+0.02%)	⬆️
superset/db_engine_specs/presto.py	84.34% <0.00%> (-5.64%)	⬇️
superset/connectors/sqla/models.py	87.07% <0.00%> (-1.13%)	⬇️
superset/models/core.py	89.26% <0.00%> (-0.74%)	⬇️
superset/key_value/commands/exceptions.py	100.00% <0.00%> (ø)
superset/dashboards/filter_state/commands/entry.py	100.00% <0.00%> (ø)
superset/utils/core.py	89.76% <0.00%> (+0.11%)	⬆️
superset/utils/cache_manager.py	100.00% <0.00%> (+3.84%)	⬆️
superset/db_engine_specs/hive.py	87.25% <0.00%> (+16.98%)	⬆️
superset/dashboards/filter_state/api.py	100.00% <0.00%> (+17.02%)	⬆️
... and 11 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8e02d11...bccf8b9. Read the comment docs.

[villebro]

Stellar work @betodealmeida ! LGTM

[etr2460]

@betodealmeida it looks like this PR broke parsing table names from queries with sub selects. Here's a repro case:

SELECT *
   FROM
     (SELECT 1 as foo, 2 as bar)
   ORDER BY foo ASC, bar

ParsedQuery now thinks that ORDER BY and bar are tables:

Do you think this is something you could easily fix, or should we consider reverting this PR? I could possibly look into fixing myself, but the sql parse codebase is something i'm a bit nervous about jumping into