Re: Error Writing/Reading Encrypted Values

I think bytea is intended for storing binary data. Not used it myself but I
think it needs 0's parsing (to \000 I believe).
- Stuart

-----Original Message-----
From: cnliou(at)eurosport(dot)com [mailto:cnliou(at)eurosport(dot)com]
Sent: 15 January 2002 06:06
To: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Error Writing/Reading Encrypted Values

Greetings! Hiroshi,

[ begin of quote ]
> > I also found in Windoz that when my encryption
> > routine aborts, the retrieved encrypted string is
> > actually corrupted - its string length is 1 byte
> > longer than it is supposed to be.
>
> There could be the following case.
>
> Windows client *nix server
>
> '\n' ---> '\n'
> (not preceded by 'r')
> \r\n <--- '\n'
>
> [ end of quote ]
>
> I will check this out.
> My C routine does not add the *unwanted* '\r'. I
> won't think delphi does that either. Does
pgsqlODBC
> do this unwanted conversion?

Yes. Do people want a new option ?
[ end of quote ]

Please first pardon my ignorance of too many things
including ODBC.

I presume all people want is a "raw" data extracted
from database without any translation except for
multi-byte characters. As in my case shows: problem
arises when char/varchar/text fields are used to
store "strange" (encrypted) characters and ODBC
"automatically" adds '\r' to these values before
returnning them to Windoz applications.

Is it reasonable and possible in technical point of
view to at least add a checkbox in ODBC indicating
enable/disable '\r' translation? Or is it true that
char/varchar/text columns were not designed to store
encrypted characters, which may contain non ascii
characters and low values, in the first place? If so,
where am I supposed to save the encrypted characters?

Regards,

CN

--------------------------------------------------------
You too can have your own email address from Eurosport.
http://www.eurosport.com