inserting binary in a bytea field

From: Olivier Jeannet <jeannet(at)montrouge(dot)tt(dot)slb(dot)com>
To: pgsql <pgsql-bugs(at)postgresql(dot)org>
Subject: inserting binary in a bytea field
Date: 2000-12-01 18:21:27
Message-ID: 3A27EC27.A061FC4E@montrouge.tt.slb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name : Olivier Jeannet
Your email address : ojeannet(at)slb(dot)com

System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium

Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.13

PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2

Compiler used (example: gcc 2.8.0) : gcc version egcs-2.91.66
(egcs-1.1.2 release)

Please enter a FULL description of your problem:
------------------------------------------------

There is a bug when inserting binary values (non-ASCII) in a bytea field,
the escape method ("\\134") doesn't work as expected.
(maybe it is not a bug)

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

Here is the script :
CREATE TABLE az( a bytea);
INSERT INTO az VALUES('\\145');
The SELECT gives 'e' which is correct as ASCII 'e' = '\145' (0x65) .

Now the problem.

With the following :
INSERT INTO az VALUES('\\002');
The SELECT gives the following result : '\002', i.e. four characters,
and not one byte with value of "2". The length of four has been checked
using JDBC.

With the following :
INSERT INTO az VALUES('\\134');
The SELECT gives the following result : '\\', i.e. a double backslash
instead of a single one.

Is this normal ?
Am I supposed to get binary values as escaped ASCII, in order to do a
"sprintf(myvar, sql_result)" to get the real data in myvar ?

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

Not known.

--
Olivier Jeannet - e-Payment solutions
I prefer not running 32 bit extensions for a 16 bit patch to an 8 bit
operating system originally coded for a 4 bit microprocessor, written
by a 2 bit company, that can't stand 1 bit of competition.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2000-12-01 18:38:14 Re: inserting binary in a bytea field
Previous Message Thomas Lockhart 2000-12-01 18:15:24 Re: Re: [NOVICE] RE: iofflush psql 7.0.3 coredump on RH 6.1