Hibernate also chooses to hide those SQL differences

Wrong. Reread my last comment. You're perfectly free to use any function, aggregate, or other feature defined only within your database when you're using hibernate. The ONLY thing the ORM is doing is combining relational with OOP. It isn't binding you to some whole new language that limits the features you can use (other than the aforementioned lack of aggregates in subselects).

It needs backend drivers to recognize the small portion of SQL that it actually uses to do such a mapping. Hiding the functionality of the database is well and good, but sometimes databases have fantastic functionality that you don't want to miss.

I don't want to be bound by the lowest common denominator of database functionality when I'm writing my code, and if Entities always requires this, then it is certainly always going to be much less functional than the databases it supports...and so will not be used.

I still use php.net a ton for the nitty gritty of everything, but for 90% of it all, I found it sometimes tedious to deal with. If you want EVERYTHING, it's great. I dunno, in a way it inspired me to write a php book because I was spending too much time trying to figure out sprintf() because it's not very beginner friendly. Since I mentioned it, I'll post a link to the book blog and the creative commons pdf version (complete): phpreferencebook.com.

I also really like going to tizag.com for their tutorials and plain jane explanations.