Thread: Rep:Re: Error Writing/Reading Encrypted Values
Hi! Hiroshi, Thank you again for the big help! [ 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? Best Regards, CN -------------------------------------------------------- You too can have your own email address from Eurosport. http://www.eurosport.com
cnliou@eurosport.com wrote: > > Hi! Hiroshi, > > Thank you again for the big help! > > [ 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 ? regards, Hiroshi Inoue
On Wed, 16 Jan 2002, Hiroshi Inoue wrote: > Cedar Cox wrote: > > > > On Tue, 15 Jan 2002, Hiroshi Inoue wrote: > > > > > cnliou@eurosport.com wrote: > > > > > > > > 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 ? > > > > Personally, I don't think I would need it, but it sounds useful (and > > needed) if there's no other place to store "strange" data. There's also > > the question of defaults. For Windows it should be the current behavior. > > For Unix, perhaps the default should be no conversion? (I don't know if > > it's difficult to set something different for another platform.. perhaps > > ignore me..?). > > It's not difficult to change the behavior between Windows > and the others. It doesn't seem that difficult to add an > option to enable/disable <LF> <-> <CR><LF> conversion either. > The problem is that we have already too many options. > The more we have options the longer the connection string > would be. We are already using abbrebiated connection > strings in psqlodbc driver and don't have many bytes > to spare for connection strings. > Well is the option worth adding ? Ok. I understand the dilemma. In that case, perhaps it would make sense for it to be a compile time option, with defaults as I mentioned. It seems most likely to be platform dependent, and probably set only once anyway. This way the windows driver at least wouldn't change at all ...back to the list. Comments anyone? -Cedar
> > > Personally, I don't think I would need it, but it sounds useful (and > > > needed) if there's no other place to store "strange" data. There's also > > > the question of defaults. For Windows it should be the current behavior. > > > For Unix, perhaps the default should be no conversion? (I don't know if > > > it's difficult to set something different for another platform.. perhaps > > > ignore me..?). > > > > It's not difficult to change the behavior between Windows > > and the others. It doesn't seem that difficult to add an > > option to enable/disable <LF> <-> <CR><LF> conversion either. > > The problem is that we have already too many options. > > The more we have options the longer the connection string > > would be. We are already using abbrebiated connection > > strings in psqlodbc driver and don't have many bytes > > to spare for connection strings. > > Well is the option worth adding ? > > Ok. I understand the dilemma. In that case, perhaps it would make sense > for it to be a compile time option, with defaults as I mentioned. It > seems most likely to be platform dependent, and probably set only once > anyway. This way the windows driver at least wouldn't change at all > ...back to the list. Comments anyone? Compile-time options are even less attractive -- perhaps some auto-sensing code that looked at the first line and determined the proper behavior. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote: > > > > > Ok. I understand the dilemma. In that case, perhaps it would make sense > > for it to be a compile time option, with defaults as I mentioned. It > > seems most likely to be platform dependent, and probably set only once > > anyway. This way the windows driver at least wouldn't change at all > > ...back to the list. Comments anyone? > > Compile-time options are even less attractive -- perhaps some > auto-sensing code that looked at the first line and determined the > proper behavior. Hmm I don't understand what auto-sensing means. At any rate I would change the behavior in the next version. regards, Hiroshi Inoue
> > > Ok. I understand the dilemma. In that case, perhaps it would make sense > > > for it to be a compile time option, with defaults as I mentioned. It > > > seems most likely to be platform dependent, and probably set only once > > > anyway. This way the windows driver at least wouldn't change at all > > > ...back to the list. Comments anyone? > > > > Compile-time options are even less attractive -- perhaps some > > auto-sensing code that looked at the first line and determined the > > proper behavior. > > Hmm I don't understand what auto-sensing means. > At any rate I would change the behavior in the next > version. For auto-sensing, I was thinking of looking at the end of the first line and seeing if it is \n or \r\n and using that to handle the rest of the lines. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > > > Ok. I understand the dilemma. In that case, perhaps it would make sense > > > > for it to be a compile time option, with defaults as I mentioned. It > > > > seems most likely to be platform dependent, and probably set only once > > > > anyway. This way the windows driver at least wouldn't change at all > > > > ...back to the list. Comments anyone? > > > > > > Compile-time options are even less attractive -- perhaps some > > > auto-sensing code that looked at the first line and determined the > > > proper behavior. > > > > Hmm I don't understand what auto-sensing means. > > At any rate I would change the behavior in the next > > version. > > For auto-sensing, I was thinking of looking at the end of the first line > and seeing if it is \n or \r\n and using that to handle the rest of the > lines. The point of this is to handle arbitrary binary data (and give people an option of CRLF translation) right? What if the "wrong" data appears? How does one auto-sense binary data? (Perhaps I'm missing something..) -Cedar
Cedar Cox wrote: > > > > > > Ok. I understand the dilemma. In that case, perhaps it would make sense > > > > > for it to be a compile time option, with defaults as I mentioned. It > > > > > seems most likely to be platform dependent, and probably set only once > > > > > anyway. This way the windows driver at least wouldn't change at all > > > > > ...back to the list. Comments anyone? > > > > > > > > Compile-time options are even less attractive -- perhaps some > > > > auto-sensing code that looked at the first line and determined the > > > > proper behavior. > > > > > > Hmm I don't understand what auto-sensing means. > > > At any rate I would change the behavior in the next > > > version. > > > > For auto-sensing, I was thinking of looking at the end of the first line > > and seeing if it is \n or \r\n and using that to handle the rest of the > > lines. > > The point of this is to handle arbitrary binary data (and give people an > option of CRLF translation) right? What if the "wrong" data appears? > How does one auto-sense binary data? (Perhaps I'm missing something..) It was just a guess. I thought it was dealing with end-of-line issues. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026