Re: Possible to run the server with ANSI/ISO string
От | Ken Johanson |
---|---|
Тема | Re: Possible to run the server with ANSI/ISO string |
Дата | |
Msg-id | 424A2143.9020504@kensystem.com обсуждение исходный текст |
Ответ на | Re: Possible to run the server with ANSI/ISO string (Ken Johanson <pg-user@kensystem.com>) |
Список | pgsql-general |
The latest mysql build (5.0.3) now supports standard backslash behavior, using the below config option. set-variable=sql-mode=PIPES_AS_CONCAT,ANSI_QUOTES,NO_BACKSLASH_ESCAPE PG seems to be the last holdout. :-) Ken Ken Johanson wrote: > [snip] > >> >> 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 > > >
В списке pgsql-general по дате отправления: