The documentation indicates that bytea will -store- binary data
The problem is getting the data into the column through SQL.
The Postgresql SQL is character data only (side note: what about unicode?
is this USASCII only?). You cannot just wrap your binary stream in a pair
of quotes and off you go. You must encode before saving and decode after
retrieving. The encoded form is stored in the column.
What I have not figured out is how to pass my data to encode.
This is a builtin function but it doesn't take a filename so how can
you use it!
At least with base64 I have ample libraries and can convert my data
before sending to sql or after receiving from sql. It becomes my
application's issue. Mind, this bloats the data considerably.
escape is less bloat but I have to recreate the encode/decode in my app,
so far as I see.
On Wed, 18
Feb 2004, sad wrote:
> On Tuesday 17 February 2004 18:08, you wrote:
>
> > I'd recommend to let the application convert the binary
> > data to and from base64,
>
> Don't, please don't !
>
> Since you have the good bytea rule to convert so called "binary" data into so
> called "text". You have no need another encoding at all.
>
> Generally, the problem is to represent zero (0x00) when input/output. Any
> other byte might be stored, dumped, input, output without any problem. Then
> why to avoid 8bit chars ?
>
> Bytea notation rule completely resolve the problem of zeroes.
> (and also apostrophes :-) naturally)
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>