Paul J Stevens wrote:
Matthew O'Connor wrote:
I'm not entirely sure of the performance or
sorting implications of this either, but I can look into it. What are
you most concerned about losing?
reliability and performance of 'ORDER BY' is my main concern here.
OK.
Are you sure that imap-sort won't behave as expected if we convert the
header columns to bytea?
No, I just don't know.
OK.
Does gmime have the ability to convert to any number of encodings? Could
we specify in dbmail.conf that our database uses a specific encoding and
have gmime do the conversion before it hits the database?
gmime uses utf8 internally all over. Casting strings from anything to
utf8 is very simple. It does *not* provide interfaces to encode into
*anything*; just locale->utf8 and utf8->locale
I just took a quick look at the gmime docs, it appears that you can use
the gmime iconv functions to do char set conversions. It might be
helpful to allow a user to specify the output charset that will be
compatible with their database, perhaps use UTF8 if unspecified. Or am
I misreading the docs? (
http://spruce.sourceforge.net/gmime/doc/gmime-gmime-iconv.html )
I'll test whether SQL_ASCCI tables will accept utf8 encoded strings. If
that's the case people can select either, so postgres users won't have
to convert their tables at all. (big plus).
I believe it will, but please test. This will give more flexibility to
be able to use UNICODE (UTF8) or SQL_ASCII, but it will still be a
problem for people who use other encoding, but perhaps we can't be all
things for all people...
