Bug #467: Can't insert a value of 0 (zero) into a Bytea type.

Billy G. Allie (Bill(dot)Allie(at)mug(dot)org) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
Can't insert a value of 0 (zero) into a Bytea type.

Long Description
It does not zeem possible to insert a value of zero (0) into a bytea type. Also, using '\134' (the octal code for a backslash) causes byteain() to generate an error message.

As a side issue, how can one tell a backslash followed by 3 digits (four bytes of data) from an encoded byte of data? It seems to me that byteaout() should always output an octal escape sequence per byte, even if the character is printable. That way the result is unambiguous in meaning (even if it is wasteful of bytes).

Sample Code
bga=# select version();
version
-----------------------------------------------------------
PostgreSQL 7.1.3 on i586-sco-sysv5uw7.1.1, compiled by cc
(1 row)
bga=# create table test6 (a bytea);
CREATE
bga=# insert into test6 values('\001\002\354ab\000de\004');
INSERT 163734 1
bga=# select * from test6;
a
----------------
\001\002\354ab
(1 row)

Note: It is possible to workaround (i.e. fake out postgresSQL) by inserting a backslash followsd by 3 zeros (a total of 4 bytes) into the bytea type. For example:

bga=# insert into test6 values('\001\002\354ab\\000de\004');
INSERT 163735 1
bga=# select * from test6;
a
--------------------------
\001\002\354ab
\001\002\354ab\000de\004
(2 rows)

This also illustrates another problem with bytea types. How does one tell the difference between a backslash followed by 3 digits (four bytes of data) for an encoded (single) byte of data?

The problem with using '\134' as input to a bytea field is illustrated here:

bga=# insert into test6 values('\134');
ERROR: Bad input string for type bytea
bga=#

No file was uploaded with this report