For future reference, it is not actually a great idea to use @compiles to render with "AT TIME ZONE" as I did above. When done this way, SQLAlchemy renders all references to that column using this, *including* any references in a WHERE clause. eg: when looking for log events later than some date you would get:
SELECT log.blah ,log.time AT TIME ZONE 'EST' -- intended use FROM log WHERE log.time AT TIME ZONE 'EST' > foo -- not intended As said above, the problem here is that the custom compilation happened in both the column specification *and* the WHERE clause. This is not surprising (with hindsight), but it prevents any index on log.time from being used (unless there is an appropriate functional index). For this case, I only wanted it applied to the column spec, not the WHERE, but I don't think this is currently possible to differentiate this and compile differently in each location... or is it? I looked into compiler.statement et al to figure out the compilation context, but could not. Russ PS: For what it's worth, for this specific case in PostgreSQL, this type of functionality is better suited to appropriate use of the "timestamp with time zone" data type, and correct session usage of "SET TIME ZONE" and/or PGTZ usage. I'm currently wrestling with the use cases here instead. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/G99byYSmjoQJ. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
