From: | Sim Zacks <sim(at)compulab(dot)co(dot)il> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: encoding confusion |
Date: | 2008-06-11 05:35:59 |
Message-ID: | g2no82$28dv$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The data in the longblob field might be text, which could be causing the
confusion. For example, when I look at the data in the longblob field, I
see /n for a newline and when I look at the bytea it is 012.
I can only tell you what happened in the client end, in terms of
corruption. I am using the Thunderbord client. When I clicked on a
message, it didn't show the data and when I looked at the headers, it
was just a big mess. I'm guessing that somehow the newlines didn't work
and the headers and message were overlaid on top of each other.
Richard Huxton wrote:
> Your Python script seems to think it's dealing it's dealing with text
> rather than a stream of bytes too. I'm not a Python programmer, but I'd
> guess it's treating one of the database fields (either MySQL or
> PostgreSQL) as text not bytes. You'll need to check the docs for
> binary-data handling in your Python libraries.
>
> I'm puzzled as to how the data was corrupted with escape_bytea() - I
> can't imagine it would be that difficult for the library to get right.
> I'd be suspicious that the source data wasn't what I thought it was.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhPZD8ACgkQjDX6szCBa+pKkwCfXwzX9iZJl6OS7gji9WXczfy7
T7UAn0sCr+Ut5lbZzXQizC8V3P/Irwrh
=/9bo
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2008-06-11 05:58:16 | Re: encoding confusion |
Previous Message | Richard Broersma | 2008-06-11 04:06:13 | what gives: SELECT INVALID SELECT STATEMENT TO FORCE ODBC DRIVER TO UNPREPARED STATE |