Instead of adding an FAQ entry, which might not be found when the error
is generated, I added a HINT for 8.2 that will appear with the error
message:
errmsg("invalid byte sequence for encoding \"%s\": 0x%s",
pg_enc2name_tbl[encoding].name,
On Thu, Jun 08, 2006 at 07:25:35AM -0400,
Douglas McNaught <[EMAIL PROTECTED]> wrote
a message of 29 lines which said:
> I would think it would (at least potentially) vary with each
> message. The dbmail software should really set client_encoding
> based on the Content-Transfer-Encoding header
Tom Lane wrote:
"Matthew T. O'Connor" writes:
They have talked about changing the messageblks to binary instead of
text. They said that one of their main objections is that bytea data is
not compressed. I'm not sure that's true, but I don't see anything in
the docs about it. I think they
"Matthew T. O'Connor" writes:
> They have talked about changing the messageblks to binary instead of
> text. They said that one of their main objections is that bytea data is
> not compressed. I'm not sure that's true, but I don't see anything in
> the docs about it. I think they would move
Daniel Verite wrote:
IMHO they fail to draw the proper conclusion, which is that
either the raw mail should be stored as either as a binary object,
or as a text field in a database with SQL_ASCII encoding, in both
cases providing the level of transparency that they need by design,
their purpose b
Daniel Verite wrote:
Matthew T. O'Connor wrote:
The basic setup is that Postfix hands the email to a program called
dbmail-smtp which parses and insert the message into the database.
DBMail doesn't know anything about encoding.
That's precisely what SQL_ASCII is for. Why not st
Tino Wildenhain wrote:
Matthew T. O'Connor schrieb:
Well, to answer my own question, I hacked the source code of DBMail
and had it set the client encoding to LATIN1 immediately after
database connect, this seems to have fixed the problem.
You could also just have set the client_encoding as a
Douglas McNaught wrote:
> I would think it would (at least potentially) vary with each message.
> The dbmail software should really set client_encoding based on the
> Content-Transfer-Encoding header in the message (or whatever it's
> called).
That would be the "charset" parameter of the
Tino Wildenhain <[EMAIL PROTECTED]> writes:
> Alban Hertroys schrieb:
>> Matthew T. O'Connor wrote:
>>
>>> Well, to answer my own question, I hacked the source code of DBMail
>>> and had it set the client encoding to LATIN1 immediately after
>>> database connect, this seems to have fixed the probl
Matthew T. O'Connor wrote:
> The basic setup is that Postfix hands the email to a program called
> dbmail-smtp which parses and insert the message into the database.
> DBMail doesn't know anything about encoding.
That's precisely what SQL_ASCII is for. Why not stay with it?
--
Daniel
Alban Hertroys schrieb:
Matthew T. O'Connor wrote:
Well, to answer my own question, I hacked the source code of DBMail
and had it set the client encoding to LATIN1 immediately after
database connect, this seems to have fixed the problem.
LATIN1 != UTF-8. Your problem isn't solved yet.
We
Matthew T. O'Connor wrote:
Well, to answer my own question, I hacked the source code of DBMail and
had it set the client encoding to LATIN1 immediately after database
connect, this seems to have fixed the problem.
LATIN1 != UTF-8. Your problem isn't solved yet.
You should either tell your cli
Matthew T. O'Connor wrote:
Well, to answer my own question, I hacked the source code of DBMail and
had it set the client encoding to LATIN1 immediately after database
connect, this seems to have fixed the problem.
Sorry for the noise,
Matt
I've seen this sort of problem asked about in the m
Matthew T. O'Connor schrieb:
Well, to answer my own question, I hacked the source code of DBMail and
had it set the client encoding to LATIN1 immediately after database
connect, this seems to have fixed the problem.
You could also just have set the client_encoding as an user-option
in postgr
Well, to answer my own question, I hacked the source code of DBMail and
had it set the client encoding to LATIN1 immediately after database
connect, this seems to have fixed the problem.
Sorry for the noise,
Matt
Matthew T. O'Connor wrote:
I'm using DBMail running against PostgreSQL as my m
I'm using DBMail running against PostgreSQL as my mailstore for our
company network. I recently converted our company database from
SQL_ASCII to UTF8 as I thought this would be a *good thing*.
The problem now is that I think I'm loosing emails because in my
postgresql logs I get this:
2006-0
16 matches
Mail list logo
