![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
|
We have a TODO item: * Allow backslash handling in quoted strings to be disabled for portability The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not SQL-spec compliant, so allow such handling to be disabled. Unfortunately that's all we have. :-) Thanks, glad to hear it's on the radar. From what I can tell it the |
#2
| |||
| |||
|
|
We have a TODO item: * Allow backslash handling in quoted strings to be disabled for portability The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not SQL-spec compliant, so allow such handling to be disabled. Unfortunately that's all we have. :-) Thanks, glad to hear it's on the radar. From what I can tell it the broadest reaching standards incompatibility in the server. And, it's |
|
preventing some project managers from adopting the server as an alternative to the commercial ones (Its always been an easy-to-cite, and well justified concern that the backslash behavior is incompatible with other DBs and specs). |
#3
| |||
| |||
|
|
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. True, but users also need (or already use) a generic, predictable |
|
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. I may have this key issue - user share.... the other large open source |
![]() |
| Thread Tools | |
| Display Modes | |
| |