Thread: Storing null bytes in bytea
Hi all, I was going to post this on the pgsql-php list but I think the issue is more on the PostgreSQL side of things. I'm using PHP 5.2.9 connected to a PostgreSQL 8.3.7 server running on Solaris 10 to try to store the session data for an application using a custom session handler class. The session data (objects/class instances etc) is serialized into raw bytes in PHP and contains a few nul/zero bytes (which are meaningful to PHP when it comes to deserializing the data.) Because of the nul bytes, I've set the session_data column to be a bytea column in my database table. However I cannot get PostgreSQL to read past the first nul byte on an insert, so the unserialize call fails when it reads it back out the database and the remaining data is omitted. An example of such query is this: INSERT INTO system.session (user_id, session_key, session_name, client_browser, date_created, date_expires, ip_address, session_data) VALUES (NULL, '4pc4sjciahoc4fuk1bt4kohe91'::character varying(32), 'AppName'::character varying(50), 'Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729)'::character varying(200), public.get_pg_timestamp(1240853862::integer), public.get_pg_timestamp(1240854162::integer), '192.168.0.8'::inet, E'IsLoggedIn|b:1;CurrentUser|O:17:"Class_SystemUser":4:{s:26:"\\000Class_SystemUser}'::bytea); All other columns are fine, but when it comes to the session_data column, all I end up with is 'IsLoggedIn|b:1;CurrentUser|O:17:"Class_SystemUser":4:{s:26:"'. Everything past the first "\\0000" byte sequence is ignored. I've tried this with and without the 'E' at the beginning of the value string. Any pointers as to what I'm doing wrong? Thanks, Andy
Andy Shellam <andy-lists@networkmail.eu> writes: > Because of the nul bytes, I've set the session_data column to be a bytea > column in my database table. However I cannot get PostgreSQL to read > past the first nul byte on an insert, so the unserialize call fails when > it reads it back out the database and the remaining data is omitted. Your example works fine in psql: regression=# create table t1 (f1 bytea); CREATE TABLE regression=# insert into t1 values (E'IsLoggedIn|b:1;CurrentUser|O:17:"Class_SystemUser":4:{s:26:"\\000Class_SystemUser}'::bytea); INSERT 0 1 regression=# select * from t1; f1 -----------------------------------------------------------------------------------IsLoggedIn|b:1;CurrentUser|O:17:"Class_SystemUser":4:{s:26:"\000Class_SystemUser} (1 row) I suspect what is happening is that some layer on the client side is doubling (or perhaps undoubling?) the backslashes for you. Exactly what are you doing with that literal as you build the query? It might help to turn on log_statements so that you can see just what the server is getting. regards, tom lane
Hi Tom, > Your example works fine in psql: > > regression=# create table t1 (f1 bytea); > CREATE TABLE > regression=# insert into t1 values (E'IsLoggedIn|b:1;CurrentUser|O:17:"Class_SystemUser":4:{s:26:"\\000Class_SystemUser}'::bytea); > INSERT 0 1 > regression=# select * from t1; > f1 > ----------------------------------------------------------------------------------- > IsLoggedIn|b:1;CurrentUser|O:17:"Class_SystemUser":4:{s:26:"\000Class_SystemUser} > (1 row) > > > I suspect what is happening is that some layer on the client side is > doubling (or perhaps undoubling?) the backslashes for you. Exactly > what are you doing with that literal as you build the query? It might > help to turn on log_statements so that you can see just what the > server is getting. > Many thanks for your reply. I was a bit naive about the quality of the client I was using (Navicat 8.1.) It turns out in the "Memo" view it doesn't show anything past the first zero byte. However switch it to hex view and you see the full bytes. I think my issue that it wasn't working on the client side (and caused me to examine it in more detail in the database) was because it wasn't unescaping correctly in the application code when it read the data back out of the database. Next time I won't be so lazy and try it out in psql first... Regards, Andy