`sqlalchemy.func` does not map anything. It is a namespace for a factory
generator. anything you access with it becomes a function of that
caller's name.
for example:
filter( func.foo(table.column) > 1 )
produces
WHERE foo(table.column) > 1
sqlalchemy generates the `foo` function dynamically though the `func`
namespace.
In your example, `func.length` creates the sql "LENGTH()" not "LEN()". It
works because your backend supports "LENGTH" not "LEN". Most databases use
LENGTH (postgres, mysql, oracle, sqlite). Only MsSQL uses LEN, and
firebird has a completely different approach with CHAR_LENGTH, BIT_LENGTH,
etc.
I don't think any more portability has ever been needed, because the
functions are either:
* standardized across most databases due to common standards
* highly specfiic to a single database
Trying to create a system that standardizes how every database handles
ancillary internal function "concepts" would be overwhelming and of little
real utility.
If you really wanted to pursue this, I'd imagine you would work on the SQL
compliler or just inspect the db connection when you generate the query and
conditionally use different forms.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
