Martijn van Oosterhout writes:
> I'm not totally sure about how ODBC works, but if it's anything like
> Perl DBI, surely it's the responsibility of the ODBC layer to escape
> the baackslashes? Maybe it depends on whether they're using
> placeholders or not...
I suppose they are not using placehol
"Frank D. Engel, Jr." <[EMAIL PROTECTED]> writes:
> Given that this issue is a violation of SQL compatibility, shouldn't
> there really be an option to turn off interpretation of backslash
> characters in string literals as escapes? Maybe as a session variable
> of some kind, with a default bei
On Fri, Jan 14, 2005 at 04:59:57PM -0500, Frank D. Engel, Jr. wrote:
> Given that this issue is a violation of SQL compatibility, shouldn't
> there really be an option to turn off interpretation of backslash
> characters in string literals as escapes? Maybe as a session variable
> of some kind,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Given that this issue is a violation of SQL compatibility, shouldn't
there really be an option to turn off interpretation of backslash
characters in string literals as escapes? Maybe as a session variable
of some kind, with a default being set in po
"aboster" <[EMAIL PROTECTED]> writes:
> Since MS-SQL & Oracle (both via ODBC) work fine with this app, I would
> suspect the issue is that Postgres is interpreting backslashes as escape
> characters in situations that the supported databases do not.
Postgres definitely considers backslashes to be
We are trying to use a suite of third party applications, which run on
Windows 2000, that can make use of a database backend via ODBC. Most of the
apps work just great with Postgres. One of the components (a key
visualization application) does not. Note that this all works fine, as is,
using Ora
