It's amazing to me that SQLRender has faired as well as it has. Clearly a general-purpose SQL translator (especially if it could cover some noSQL cases as well -- Hadoop, GBQ?) would be a huge boon to the database world. The only reason a great solution doesn't exist, I would assume, is because the problem is too hard. Yet SQLRender has managed to hold this community together despite our commitments to disparate DBMSs.
But one has to ask, especially in light of a planned rewrite, at what cost? And are there alternatives? I believe Patrick, Frank, and Martin, and probably others who have thought much longer than I have about this challenge, have concluded that we can't escape our dependence on SqlRender whatever its flaws.
But I, for one, and I imagine I'm not alone, am disturbed at the thought that the tools I develop are unlikely to gain community adoption if I don't write my SQL in MSSQL or OHDSI-SQL -- 1) because I have no way of running those languages right now, and 2) because the SQL code I write tends to be very hairy and I tend to rely on every bell and whistle available in whatever flavor of SQL I happen to be using (right now PostgreSQL) and automated translation of it would likely be impossible.
I don't have a great solution right now, but I'm curious to know how much others share my concerns as we contemplate new investment in SqlRender.