\n converted to \r\n

Hello,

I'm currently running version 07_03_0200 of the Insight Distribution
Systems PostgreSQL Driver for windows. when I retrieve col1 string
from the database using: "SELECT * FROM MyTable WHERE col1='hello\n'"
the value returned for col1 through the driver is "hello\r\n", and I
want it to be as it is stored in the database ('hello\n" with no \r).
Is this a configuration issue? If so, where can I change the
configuration to ensure that this conversion won't happen?

Thanx in advance for your help, amir

PS: This is a mailing list thread I ran across that had the same
problem. does anybody know if the bug has been fixed? I tried
contacting Byron, but his email is no longer valid:

Date: Fri, 09 Apr 1999 18:46:00 -0400
From: Byron Nikolaidis <byronn(at)insightdist(dot)com>
Subject: Re: [INTERFACES] ODBC Driver v06-40-0005

Sam O'Connor wrote:

> Hi,
> I think I found another problem.
> When selecting type text from tclodbc using pgodbc and postgres I was
> loosing
> one character off the start of the string for every newline in
> contained.
> When copy_and_conver_field processes selected text fields it converts cr
> to cr/lf. (why?)
>

Actually, its LF to CR/LF when going from the database to odbc. When going the
other way (odbc->database), it converts CR/LF to LF. The reason is for
Microsoft from what I remember. It might have even been in the odbc spec (I
can't quite remember). It probably shouldn't do it if its being run on Unix
though?

> When data_left is set how ever it uses the original length.
>
> I changed this:
> stmt->bindings[stmt->current_col].data_left = strlen(value);
> To this:
> stmt->bindings[stmt->current_col].data_left = strlen(ptr);
>
> Now it works!
>

Good Job, you found a bug alright! It should be strlen(ptr). When I tested
it, I didn't have newlines so it worked ok.

I'll put it in for the next release.

Byron