Thu, 09 Apr 2026 17:42:22 +0000 https://bugs.horde.org/ticket/10919 Postgresql 9.0 bytea output is hex and should be escape 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) With "ALTER DATABASE horde SET bytea_output = 'escape'; " you can change the output postgresql uses. If this isn't done. all pref_values in horde_prefs are corrupted. I had the problem when updating horde groupware webmail edition from 4.0.3 to 4.0.4 and 4.0.5. If I got this correctly the following happened: 4.0.3 -> 4.0.4 horde changed from using plaintext values in pref_value to using binary values, without changing the type of pref_value (it had still the type text). This wasn't that big a problem. the values looked somehow weird, but it worked quite a while. 4.0.4 -> 4.0.5 pref_value was changed from type text to type binary, also converting all the values. This lead to corrupted values. The pref_value field had the correct information in it, but also a lot of completely useless information (mostly long sequences of the number 3, some other numbers mixed in from time to time. A single pref_value had more than 1 million signs alltough only a name and an e-mail address were stored). This happened because postgresql sent the bytea values as hex instead of escape format. Changing the bytea_output from hex to bytea solves the problem. So the following line should be in the update scripts and in the create database script for postgresql 9.0 ALTER DATABASE horde SET bytea_output = 'escape'; Thu, 12 Jan 2012 14:01:53 +0000 https://bugs.horde.org/ticket/10919#t69794 > 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. 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: The bytea type always accepts both formats on input, regardless of this setting. You are going to have to come up with a failing unit test to prove otherwise. Fri, 27 Jan 2012 08:26:14 +0000 https://bugs.horde.org/ticket/10919#t69955 >> 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. Mon, 21 Oct 2013 17:56:34 +0000 https://bugs.horde.org/ticket/10919#t81159 Turns out this error s due to the version of the libpg not being recent enough to work with the new 9.x default of returning bytea data as hex. I.e, If you uppgrade pgsql to 9.x you MUST make sure you recompile or update pdo_pgsql with version libpg >= 9.2 (9.1.x was tested and is broken in this regard). Mon, 21 Oct 2013 21:32:04 +0000 https://bugs.horde.org/ticket/10919#t81161