content: 
  New set of tests for new typechecking. Will catch more issues than the
  old typechecker, and the tests are focus on lots of checks for bad
  typechecks as well as correct queries compared to the old tests.
  
  > {-# LANGUAGE OverloadedStrings #-}
  > module Database.HsSqlPpp.Tests.TypeChecking.QueryExprs
  >     (queryExprs) where
  
  > import Database.HsSqlPpp.Catalog
  > import Database.HsSqlPpp.Dialect
  > import Database.HsSqlPpp.Internals.TypesInternal
  > import Database.HsSqlPpp.Tests.TestTypes
  > --import Database.HsSqlPpp.Internals.AstInternal as A
  > --import Database.HsSqlPpp.Tests.Parsing.Utils
  > --import qualified Data.Text as T
  > import qualified Data.Text.Lazy as L
  
  > queryExprs :: Item
  > queryExprs =
  >   Group "queryExprs" [
  >       tcQueryExpr simpleTEnv
  >         (L.concat ["with tbl1(c,d) as (select a,b from tbl), tbl2(e,f) as (select c,d from tbl1)"
  >                   ," select c,d,e,f from tbl1 join tbl2"])
  >         $ Right $ CompositeType [("c", mkTypeExtra typeInt)
  >                                 ,("d", mkTypeExtra $ ScalarType "text")
  >                                 ,("e", mkTypeExtra typeInt)
  >                                 ,("f", mkTypeExtra $ ScalarType "text")
  >                                 ]
  >   ]
  >   where
  >     simpleTEnv = [CatCreateTable ("public","tbl")
  >       [("a", mkCatNameExtra "int4")
  >       ,("b", mkCatNameExtra "text")]]
  >     typeInt = ScalarType "int4"
  >     tcQueryExpr cus =
  >         let cat = makeCatalog postgresDialect cus
  >         in TCQueryExpr cat defaultTypeCheckFlags {tcfDialect=postgresDialect}
  
  = basic select list
  
  column name
  *
  aliases
  correlation names
  
  can embed in view to check additional stuff like no duplicate or
  unnamed columns
  
  = from
  
  tableref
  funtableref
  subquery tref
  join
  parens
  aliases
  lateral
  
  = set valued functions in select list
  
  = aggregates
  
  == simple
  == with extra exprs
  == in other contexts
  == grouping set stuff
  == having
  = windows
  
  = orderby
  = where
  = csq
  = distinct
  = set ops
  
  = limit, offset
  
  
  = additional scalar expr syntax tests
  
  where, having, order by, limit, offset
  
  
  
  = errors
  
  what kind of errors can there be with a sql statement?
  
  static errors: these are errors which can be detected with syntax
  analysis and static checking without executing anything (and before
  any cost based optimiser)
  
  transaction errors: these are errors which occur because of
  transactions and concurrency. Some other transaction can commit first
  and then your transaction fails and cannot work (e.g. someone drops a
  table you are referencing), and you can have serializable errors which
  you can just retry and expect it to work.
  
  'dynamic' errors: bad parses, arithmetic overflow, etc. These are
  errors which only occur during statement execution. Are they all
  related to data type conversion and/or scalar functions (maybe also
  aggs and windows?). can other phys ops fail like this?
  
  apparent hanging? is this an error? this means stuff like the cost
  based optimiser takes forever (or even some other part of the
  statement compiler), or the runtime takes forever (e.g. some
  degenerate sort means it does a new io for each row and it never
  completes). Real hangs should only occur from programmer errors. We
  should have methods to detect and recover from these (cancelling a
  statement or connection, and restarting the server process for
  instance).
  
  unexpected errors: these can come from programming errors, e.g. assert
  or bad memory writes, or running out of memory (this is a programmer
  error), or from hardware issues
  