[Tickets #10919] Re: Postgresql 9.0 bytea output is hex and should be escape

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10919
------------------------------------------------------------------------------
  Ticket             | 10919
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Postgresql 9.0 bytea output is hex and should be escape
  Queue              | Horde Base
-Version            | 4.0.13
+Version            | Git master
  Type               | Bug
-State              | Not A Bug
+State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-10-21 17:56) wrote:

>> In PostgreSQL 9.xx bytea values have hex as default output, but horde
>> expects escape.
>> (http://www.postgresql.org/docs/9.0/static/release-9-0.html)
>
> No.  We don't expect anything.  PDO handles result parsing.

This is not true, at least not in current code.

> We have unit tests that test exactly this and they work fine.
>
>> With "ALTER DATABASE horde SET bytea_output = 'escape'; " you can
>> change the output postgresql uses.
>
> No.  We don't care what the output is - that is for PDO to worry  
> about.  The only thing we care about is how to insert data into the  
> DB.  And as is clearly discussed from that above page:

Not true.  The database returns the data either as hex data, or  
escaped octal depending on the server's bytea_ouput setting. We expect  
the later. See Horde_Db_Adapter_Postgres_Column::binaryToString(). In  
Postgres 9.x, with bytea_output set to 'hex' (the default in Postgres  
9) the regexp will NOT match. PDO doesn't care what the value of this  
setting is, it returns it as -is.

> The bytea type always accepts both formats on input, regardless of  
> this setting.

Yes. It accepts the data for WRITING regardless of the setting, but it  
will presented back to client code differently depending on the  
setting. Using an ALTER database statement is one way to fix, but  
another is to provide "options: --bytea_output=escape" in the  
connection string.