BUG #5854: base64 decode returns bytea and no text

Started by chris r.about 15 years ago3 messagesbugs
Jump to latest
#1chris r.
chricki@gmx.net

The following bug has been logged online:

Bug reference: 5854
Logged by: Chris R.
Email address: chricki@gmx.net
PostgreSQL version: 9.02
Operating system: CentOS 5.5
Description: base64 decode returns bytea and no text
Details:

There is a break in how pg9.0 handles decoding base64 encoded data.

With PostgreSQL 8.4:

select decode(encode('abc', 'base64'), 'base64');
decode
----------
\x616263

With PostgreSQL 9.0:

select decode(encode('abc', 'base64'), 'base64');
decode
----------
\x616263

To get the old result, convert_from helps out:
select convert_from(decode(encode('abc', 'base64'), 'base64'), 'UTF8');

Still, shouldn't this be consistent with 8.x and 9.x?

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: chris r. (#1)
Re: BUG #5854: base64 decode returns bytea and no text

"Chris R." <chricki@gmx.net> writes:

There is a break in how pg9.0 handles decoding base64 encoded data.

This has nothing to do with decode(), it's a change in the default
output format for bytea data. Set bytea_output to "escape" to get
the old format.

regards, tom lane

#3Bruce Momjian
bruce@momjian.us
In reply to: chris r. (#1)
Re: BUG #5854: base64 decode returns bytea and no text

Chris R. wrote:

The following bug has been logged online:

Bug reference: 5854
Logged by: Chris R.
Email address: chricki@gmx.net
PostgreSQL version: 9.02
Operating system: CentOS 5.5
Description: base64 decode returns bytea and no text
Details:

There is a break in how pg9.0 handles decoding base64 encoded data.

With PostgreSQL 8.4:

select decode(encode('abc', 'base64'), 'base64');
decode
----------
\x616263

With PostgreSQL 9.0:

select decode(encode('abc', 'base64'), 'base64');
decode
----------
\x616263

To get the old result, convert_from helps out:
select convert_from(decode(encode('abc', 'base64'), 'base64'), 'UTF8');

Still, shouldn't this be consistent with 8.x and 9.x?

Uh, they look the same to me. cut/paste error?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +