But perhaps it's just a matter of getting used to a different format.
[1] Legacy environment.
[2] Edited to add: most of our newer apps don't actually invoke huge queries from the app layer. We now tend to layer a view or pl/sql table function on top of the hairy query, so that at the app level it's mostly "select * from blah." For that simple a query, a DSL like this is probably fine, albeit, unnecessary.
And if so, can I use SQLAlchemy as a standalone pre-processor? My app's in Rails so I can't exactly go integrate it..
yes. many DB specific constructs are included and you can make your own: http://www.sqlalchemy.org/docs/core/compiler.html
philosophically SQLA does not consider "abstraction" to be "hiding", so ultimately no features of the backend store are concealed
> like create a Postgres user-defined type
sure, the ENUM type does this right now automatically (i.e. CREATE TYPE...AS ENUM). For other kinds of PG types, you can emit the CREATE TYPE yourself then link to it with a SQLAlchemy-side custom type. You can integrate those two steps also.
> or a SQL function?
Again a SQL function you're going to be using PG's PL/pgSQL or other embedded language to create it, so you roll the CREATE FUNCTION yourself, then call it on the Python side using func: http://www.sqlalchemy.org/docs/core/tutorial.html#functions
I'm not a Clojure user but as I have some authority on this subject I can illustrate your query as SQLAlchemy: