If the translator supports "select expressions" or inline views, then in many circumstances we will add aliases - even if the query may be more simplistic and not need them. In general adding the aliases prevents issues with inline view column naming and keeping track of order by expressions. This was probably a behavior change for you after TEIID-1929, which fixed the inline view naming issue. You should typically not see aliases in the source query unless there is an inline view, order by, non-column select expression, limit clause, or it is a set query. What circumstances can you handle aliases in?
Our translator should support select expressions and inline views as there are many SQL's which gets executed through this translator.
Also, I think we need to make changes in our translator to support this.
The SQL which we get in the translator has some extra columns and we need to remove those columns from the SQL before passing it to our product which executes it and returns the results.
My translator extends the ExecutionFactory. I have a regular expression which checks the SQL and removes the unnecessary columns from the SQL.