Backslash as ordinary char vs. not; set via a connection/session variable
От | Ken Johanson |
---|---|
Тема | Backslash as ordinary char vs. not; set via a connection/session variable |
Дата | |
Msg-id | 44C8FB3B.9090507@kensystem.com обсуждение исходный текст |
Ответы |
Re: Backslash as ordinary char vs. not; set via a connection/session variable
Re: Backslash as ordinary char vs. not; set via a connection/session |
Список | pgsql-general |
Tom and folks, Will it be possible to set this more standard backslash handling behavior -- and possibly similar conformance modes... in a way similar to how mysql allows? They allow one to issue commands on the connection like: SET SESSION sql_mode = 'NO_BACKSLASH_ESCAPES,IGNORE_SPACE,ANSI' The advantage to this is that ISPs, etc can, by default, run the database with the old/incorrect mode (which is more compatible with the correspondingly legacy/broken apps.. and for newer apps to issue that command to make the DB act more standards compliant.. I personally have no need for the old backslash behavior (currently using databases/queries that don't use it), but sometimes one may have to coexist in a shared server environment. (for those who may not know,) the actual overhead of issuing that command (on the client side at least) before each exec is low, since connection pools for example usually already need to issue a 'ping' command (e.g SELECT 1) to test the connection before executing on it. So if the pool/api allows the user to define connection-setup DML, that conveniently takes the place of the ping anyway (if the API supports). And, given that the last user of a pooled connection may have tweaked the settings, it's prob. best to reset them before each exec. I seem to have lost the URL that describes the upcoming string conformance mode.. can't find the 4.1.2.1 section that John Gunther mentioned.. does anyone have that handy? Thank you, ken
В списке pgsql-general по дате отправления: