php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #35800 pg_query_params fails to escape NULL in bytea fields
Submitted: 2005-12-25 12:53 UTC Modified: 2012-04-17 10:45 UTC
Votes:21
Avg. Score:4.8 ± 0.4
Reproduced:18 of 18 (100.0%)
Same Version:4 (22.2%)
Same OS:2 (11.1%)
From: vinny at xs4all dot nl Assigned: yohgaki (profile)
Status: Wont fix Package: PostgreSQL related
PHP Version: 5.1.1 OS: winxp sp2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: vinny at xs4all dot nl
New email:
PHP Version: OS:

 

 [2005-12-25 12:53 UTC] vinny at xs4all dot nl
Description:
------------
pg_query_params() stops processing binary 'bytea' field data at hex '00'.



Reproduce code:
---------------
<?php
/**
create a PostgreSQL database (I used 8.1) with a table that has a 'bytea' field. Use pg_query_params to insert binary data from a JPG image into the bytea field, something like:
*/

pg_query_params("INSERT INTO tabel (byteafield) values ($1)", file_get_contents('file.jpg'));
?>



Expected result:
----------------
The image should be stored in the database completely.

Actual result:
--------------
Only the first four bytes of the JPG data make it into the database.

JPG data starts with: hex FF D8 FF E0 00 10 4A 46 49
Apparently pg_query_params stops processing the content at '00' which I guess is because PHP thinks it is at 'EOF'.

If you insert the data with a normal pg_query call and using pg_escape_bytea() on the JPG data then everything works just fine and the image is stored properly.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-10 14:09 UTC] burleybutler at hotmail dot com
I too found using a parameter doesn't work for uploading bytea binary data - either unescaped (zero bytes got saved) or using pg_escape_bytea (too many bytes got saved). Was hoping it would get around the memory/speed problems with pg_escape_bytea for large chunks of data.
 [2011-01-01 23:12 UTC] jani@php.net
-Package: Feature/Change Request +Package: PostgreSQL related
 [2011-01-26 15:11 UTC] wmoran at potentialtech dot com
I can confirm this problem on FreeBSD 8.1 with PHP 5.3.5 and PostgreSQL 8.4.6.

Note that it is ONLY parametrized queries that exhibit the problem.  Proper use of pg_escape_bytea() and pg_unescape_bytea() works as expected.
 [2012-03-31 05:30 UTC] yohgaki@php.net
I guess this is C string issue and still outstanding.
 [2012-03-31 05:30 UTC] yohgaki@php.net
-Assigned To: +Assigned To: yohgaki
 [2012-04-17 10:45 UTC] yohgaki@php.net
I thought it was C string issue, but it appears that users should use 
pg_escape_bytea().
 [2012-04-17 10:45 UTC] yohgaki@php.net
-Status: Assigned +Status: Wont fix
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 10:01:28 2024 UTC