Matthew O'Connor wrote:
> So what do all the users who's databases aren't in SQL_ASCII supposed to
> do? Any why not convert those columns to bytea now? I think it's
> better to byte the bullet now (sorry about the pun) and wait a few more
> weeks rather than push out the 2.2 release too soon.
d
So what do all the users who's databases aren't in SQL_ASCII supposed to
do? Any why not convert those columns to bytea now? I think it's
better to byte the bullet now (sorry about the pun) and wait a few more
weeks rather than push out the 2.2 release too soon.
BTW, I'm willing to help if I
I have not fully reverted to 2.1.7 behaviour.
Postgresql users will have to use SQL_ASCII encoding until we migrate al
relevant columns to bytea.
This will be done, but not in 2.2
Paul J Stevens wrote:
>> So, koi8-r text is inserted into dbmail_headervalue with convertion to utf
>> and to dbma
> So, koi8-r text is inserted into dbmail_headervalue with convertion to utf
> and to dbmail_envelope "as-is"
> Is this as expected?
No. I've removed one last remaining conversion to utf8 outside of the
pgsql driver.
--
Paul S
Hello
> Oleg please try rev 2348
>
> I've reverted the utf7 encoding on subject in envelope. Apparently it
> wan't encoded right anyway.
>
> I've also pushed the utf8 encoding to the postgres driver, so it won't
> affect mysql/sqlite users.
I try revision 2350 with my "test message"
and what I ge
Oleg please try rev 2348
I've reverted the utf7 encoding on subject in envelope. Apparently it
wan't encoded right anyway.
I've also pushed the utf8 encoding to the postgres driver, so it won't
affect mysql/sqlite users.
--
Pa
> That's unrelated. The envelope cache should always be 7bit clean.
> Subjects should be utf7 encoded to begin with, and if they are not they
> are utf7 encoded by dbmail during the construction of the imap envelope
> string. There's no utf8 conversion done along the way.
>
> Could you provide me w
Oleg Lapshin wrote:
> Hello
>
>> I've just landed a change that will convert all strings inserted into
>> the headervalue and subjectfield columns into UTF8 encoded strings using
>> a gmime's iconv facilities. The subject and address parts of the
>> envelope are encoded as utf7 (rfc2047) also ma
Hello
> I've just landed a change that will convert all strings inserted into
> the headervalue and subjectfield columns into UTF8 encoded strings using
> a gmime's iconv facilities. The subject and address parts of the
> envelope are encoded as utf7 (rfc2047) also makes it safe to insert them
> i
Matthew T. O'Connor wrote:
>> 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 flexib
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 t
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.
> Are you sure that imap-sort won't behave as exp
Paul J Stevens wrote:
For a very long time postgresql users have complained about charset
incompatibilities in dbmail.
This is only a problem for PostgreSQL users that have an encoding other
than SQL_ASCII, the PostgreSQL SQL_ASCII encoding basically ignores
encoding completely, which is a go
Charsets are a Nightmare!!
We know one thing for sure, converting between charsets is very ugly,
this lesson was learned when trying
to synchronise a swedish (latin9) cvs with svn which is UTF8
The above problem was in the fact, that svn was implemented UTF8
without backsight to the possib
Hi all,
For a very long time postgresql users have complained about charset
incompatibilities in dbmail.
Typically errors like "invalid byte sequence for encoding ..." would
break delivery of messages when the string being inserted in the
database was differently encoded than postgres was expec
15 matches
Mail list logo
