# Areas of future interest

Here are some areas of future interest. Consider them an enumeration of "R&D
areas" rather than a technical roadmap:

* The most obvious work is to **expand the parsing coverage**, both by adding
  support for more SQL dialects (e.g. Postgres, Mysql, Sqlite) and by adding
  support for the long tail of infrequently-used language features in existing
  SQL dialects.

* Another logical extension is to add support for **query translation**. It
  would require implementing a `render` function as the inverse of the `parse`
  function: `render` would transform an AST into a string in a particular
  dialect. Once implemented, query translation would be accomplished by parsing
  a query in one dialect, then rendering it into another dialect.

* A more exploratory project is to implement **type-checking of SQL**, with the
  goal of detecting errors in queries through static analysis. The principle is
  to define the types of columns, then use type-inference rules to look for
  type errors in queries, such as "column A and column B are being compared for
  equality, but have incompatible types".

  *  In practice, this would probably start by seeding the catalog information
     with annotations for the business types of certain columns. Then, the
     types of other columns would be inferred, using known or observed
     relationships between columns. For example, a known foreign-key
     relationship would generate the inference that the foreign key has the
     same type as the primary key. Alternatively, a list of candidate
     relationships could be generated by applying type-inference rules to the
     stream of queries. For example, if two columns are related by an equality
     or inequality operator, then they have compatible types.

* There are non-trivial use cases for **concrete evaluation of queries**. At
  first glance, the idea of "put in sample data, get sample results" may seem
  redundant when one could just use an actual database. However, concrete
  evaluation would allow QuickCheck for queries. Imagine an interface that let
  users specify a query to be tested, as well as post-conditions in the form of
  SQL queries that relate the original data to the output data. The QuickCheck
  test would generate arbitrary input data sets, run the query, and assert the
  post-conditions. It would then produce minimized examples failing those
  post-conditions. Now, imagine applying that to a set of queries, such as the
  steps in an ETL to produce a dimensionally modeled table.

  *  Post-condition queries would produce one row with one column with a
     boolean value (True or False). Such a query could also be called an
     assertion, predicate, or property.

* There are similar use cases for **generating arbitrary queries**. Arbitrary
  queries would allow for QuickCheck testing of databases themselves,
  particularly for catching errors in parsing. Subsequently, generating
  arbitrary table data would permit catching errors in execution.

* We could enrich our understanding of data access patterns by adding support
  for **fingerprinting of queries**, to categorize similar queries together. A
  single query could have multiple fingerprints under different fingerprinting
  algorithms. For example, a "table fingerprint" could be generated by hashing
  a sorted list of all the tables that appeared in the query. A "template
  fingerprint" could be generated by removing all constants and literals in the
  query, then hashing the resulting querystring. This algorithm would give the
  same fingerprint for `SELECT * FROM foo WHERE date > '2018-01-01'` and
  `SELECT * FROM foo WHERE date > '2018-01-02'`.

* We could **improve SQL hygiene** by adding support for query standardization
  in the same spirit as [gofmt](https://blog.golang.org/go-fmt-your-code).
  Query standardization would include auto-formatting of whitespace like line
  breaks and indentation and afford communally-owned queries all the same
  benefits described in the gofmt blogpost: queries would become easier to
  read, easier to write, easier to maintain, and less controversial. More
  aggressive formatting changes would also be possible, such as removing unused
  clauses in a query.