You're getting downvoted, but I'll reply anyway -- I agree completely.
If you're typing raw SQL for getting reports out of a database then you're probably fine, but for web apps you're not typing queries, you're constructing them as strings using another language.
I've always hated the idea of writing one language in another, it feels like a giant eval() in JavaScript/PHP/etc. Not to mention it opens you up to injection attacks.
I like programatic access like MongoDB has, it certainly has its downsides but I prefer talking to a database via an API.
Surely any time you have a data store that can work with multiple programming languages and platforms you're going to end up with an abstraction layer because of different programming languages' data representation?
Even for things as simple as integers, do you have unlimited precision, unsigned value support and null values?
Opening you up for injection attacks? Only if you're using a language that doesn't support parametrized queries/prepared statements. Add ORMs to that, and you are using an API to talk to your database.
There are certain cases I run into where PostgreSQL doesn't support parameterization. For example, utility statements in PostgreSQL have no associated plan, so they have no parameters. If you want to run a utility statement (like CREATE ROLE or DROP ROLE) you have to do so via string concatenation. This is true even in stored procedures which gives you the uncomfortable possibility of SQL injection occurring inside a stored procedure already running with elevated permissions.
This is actually one area where PostgreSQL really shines. With LedgerSMB we define our interfaces in the db (as stored procs) and then have a very simple query mapper function which looks up the stored procedure in the system catalogs and then figures out the arguments. We have a second function which then generates a query based on supplied args and runs it.
No other app code since we started this (at least code in the new framework) includes any SQL. All the SQL stuff is done by one simple function. The real programming is in the database for this interface. Our approach isn't fully developed. I expect we will be working on an object-oriented interface inside PostgreSQL soon which will make the queries look like:
SELECT (f).* FROM (select entity(?, ?, ?, ?, ?).save) f;
save(entity) will then handle actually saving the data.
If you're typing raw SQL for getting reports out of a database then you're probably fine, but for web apps you're not typing queries, you're constructing them as strings using another language.
I've always hated the idea of writing one language in another, it feels like a giant eval() in JavaScript/PHP/etc. Not to mention it opens you up to injection attacks.
I like programatic access like MongoDB has, it certainly has its downsides but I prefer talking to a database via an API.