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
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