inserting binary in a bytea field - Mailing list pgsql-bugs

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


Your name        :    Olivier Jeannet
Your email address    :       ojeannet@slb.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.