I think most people agree that being SQL compliant is good. The question is: is it worth the pain for existing users?
My guess is that it is worth it, if the users are given the discretion of treading that water.. and to save them future pain by encouraging them to migrate toward 'other-db' compatibility (or merely to migrate to PreparedStatement to eliminate worry and *insure* interop).
But where things are right now, I *know* allot of apps specially coded for PG (or mysql) --- using functions like PHPs escapeCslashes()... so they are NOT compatible apps with other DBs. So making the change would at least raises author awareness to use PreparedStatements instead (half the battle is won then because when a PS admin turns on the new escape, their apps still works correctly), or stop using escapeCslashes in favor of a sql-escape function (yes, not 'old pg' compatible, but be able to claim interop with other dbs).
A configurable option does not make the pain disappear. Admins are forced to choose one side (either sql compliant or c style) and exclude the other applications. Any app developer that wants to support pre-8.1 apps will have to have a c-style app available. So even if you nip it in the bud, it's not really gone yet because app developers want to support old versions of postgres.
As was mentioned earlier, this may not be too much of an issue if the new drivers supported an option in the getConnection call that turned on the new escape, otherwise leaving old escape turned on by default. Sort of like the jdbc version/conformance level that jdbc drivers can report through function calls. In fact PG could forever use the old style escapes by default, except when a modern driver connected to it and they both agree to use the new style.
I know if we added the option and deprecated the old style, I would be forced to choose between using deprecated syntax that may not be supported for long, or doing a lot of work to convert and retest applications.
Yes - and your app would be inter operable with Oracle, Sybase, etc and have a wider audience (moot point if you use prepared statements obviously) especially in the enterprise... Very worthwhile, imo.
Besides, the version-deprecation / version requirements you mention exists in every piece of software I've even seen. Sometime they're okay with a really old version, sometime only the newest will do. This is the very argument for getting PG to offer an (use-optional) escape behavior inline with the rest - to mitigate these version requirements down the road.
I think you may have misunderstood what I meant. I am not suggesting that we don't change the database at all between versions, my argument was showing the difficulties when one version has many different shapes due to many incompatible options.
Sorry, I misunderstood. Your point is well taken, and I agree.
Thank you, ken
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
