The easiest thing that I've found to do is:
INSERT ... decode('string','base64')::bytea ....
and
SELECT ... encode(attr1,'base64')::text ...
where attr1 is the BYTEA attribute, and 'string' is a string of base64-encoded
data. You can also use 'hex' instead of base64.
This works well because most languages have a good way to do either a
binary->hex->binary conversion or a binary->base64->binary conversion.
I don't really see a way postgres could do it any better, since the queries
and results are both strings, so there have to be rules about what a string
might include. Base64 works nicely because it's fairly compact, and all
"safe" text.
Regards,
Jeff
On Friday 20 September 2002 12:57 am, Timur V. Irmatov wrote:
> Hi, people!
>
> I've used PostgreSQL for few months and it fully satisfies my needs.
>
> Now I'm starting to explore BYTEA type (for storing small 1-5 Kb png
> images) and found it very cumbersome.
>
> I'd like to hear background explanation of why strings used as bytea
> literals pass two phases of parsing? it seems very odd to me to escape
> backslash two times (like that: '\\\\' ) just to insert it into
> string.. It adds more complexity to apps, forcing it encode/decode
> those literals..
>
> I think it would be enough to quote it like any other string, just for
> parser to understand it correctly, and insert into table. Bytea is
> binary data by it's nature, why to quote it when I perform selects?
> I'm not going to show it to humans, it is just data for my
> application.
>
> And if bytea really is displayed to a human then translating value into
> readable form (quote non-printable characters etc.) is a task of the
> application (psql, my app ..) but not PostgreSQL backend's.
>
> Any comments?
>
> Timur.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
