On 2008-04-01, Peter Gammie wrote:

On 31/03/2008, at 11:42 PM, Bjorn Bringert wrote:

...

2008/3/26 Adrian Neumann :

...

Hi,

I wrote a CGI program to access a Postgres database using HDBC. [...]

I think that Peter Gammie (copied) has some code to deal with this.

I added some stuff to HSQL (not HDBC) and HaskellDB so that UTF8 can be used to talk to the database. It's not very pretty though, so I haven't tried to get it merged.

Do you have a diff somewhere? I'd be interested in your approach, to see if the same thing would make sense in HDBC. I had generally been of the opinion that HDBC should just pass data through, however it is obtained, and let the programmer set the encoding as desired. If this approach isn't working for people, I'd like to fix it, but want to make sure it's done right.

On 2008-04-04, Peter Gammie wrote:

...

through, however it is obtained, and let the programmer set the encoding as desired. If this approach isn't working for people, I'd like to fix it, but want to make sure it's done right.

Assuming you're talking about the FFI's mandated behaviour, I'm not very comfortable with the encoding depending on the C locale, for two main reasons:

- the program I'm hacking runs on some web host's server that is an unknown quantity. - GHC has a few quirks in how it implements the FFI, better to avoid the part that interprets characters.

If you want to be general, I guess you could abandon String (at the HDBC level) and use [Word8]/ByteString everywhere, then provide some convenience wrappers. Then you can uniformly handle binary and textual data. I am not familiar with your project though.

I've looked at the Data.ByteString.Internal API, and it looks like that ought to work. Oddly, the Data.ByteString.Lazy.Internal API does not seem to export enough to work with it in FFI. I can see this being a performance and ease-of-use win in some situations. I don't think it's an actual feature difference, though. If you can represent it as a [Word8], you can represent it as a [Char], and it will be converted to the same underlying data for the trip through FFI. -- John

On 04/04/2008, at 9:27 PM, John Goerzen wrote:

I can see this being a performance and ease-of-use win in some situations. I don't think it's an actual feature difference, though. If you can represent it as a [Word8], you can represent it as a [Char], and it will be converted to the same underlying data for the trip through FFI.

Sure. I prefer to keep things separate: Char is for Unicode characters, [Word8]/ByteString is for concrete representations. It's more about type safety than efficiency. cheers peter