True, but users also need (or already use) a generic, predictable SQL-escape function (mere apostrophe doubling) from their API, that needs to work for any database..., but when they try to use it with pg, they are blindsided when they realize backslash characters are lost (I know of one company that committed to PG and had to back out after they eventually realized the backslash issue (porting issue) was too burdensome for their large codebase - sad).We don't hear it very often, perhaps once every four months. You have to double single quotes from user data anyway so most of our interfaces have a function that does this and handles backslashes too.
Unfortunately many APIs dont have the prepared statement style automatic string escaping available; more importantly, prepared statements dont work well some highly complex, programaticly generated SQL statements, and a generic Sql escape function is far easier to use (in my experience).
I may have this key issue - user share.... the other large open source DB is adding this compliance-mode at the request of SAP, so this will leave postgres as the last one standing... so to speak. ;-) Since incorrect SQL escaping has been a key reservation about (both) these DBs for users in transition (from commercial DBs), this last mile of compliance (of this magnitude) will benefit its benefactor with the market share of those awaiting masses :-)Our TODO list probably has even more items you could cite as reasons _not_ to use PostgreSQL. :-) When it becomes a key issue for someone I suppose they will code a fix for it.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
