The behavior is to be expected. The PostgreSQL documentation[1]
explains:

| Values of type character are physically padded with spaces to
| the specified width n, and are stored and displayed that way.

The PHP pgsql extension simply uses the value retrieved by
PQgetvalue()[2] and there doesn't appear to be a way to get the
actual string length (PQgetlength() returns n for char(n) columns)
(except for explicitly querying the length()).

[1] <http://www.postgresql.org/docs/8.2/static/datatype-character.html>
[2] <https://github.com/php/php-src/blob/php-5.6.10/ext/pgsql/pgsql.c#L2759>

I think we shouldn't trim result returned from PostgreSQL. So it cannot be fixed.

BTW, PostgreSQL works better(faster) with TEXT than CHAR().

I don't agree that this behavior is to be expected.
PHP should respect the semantics of the database.

I have included length and concatenation operations from the database which clearly show that the database (Postgres) treats char columns as right trimmed in these operations. When we retrieve these values through PHP, the semantics of the database should be preserved.

The problem arose by migrating an application from MySQL to Postgres. The Mysql interface (the old one) handles the strings with right trim according to the database semantic.

The consequences of handling the same column type from different databases in a different way in PHP are very surprising: e.g. the comparison of two retreived values from two different char columns with differing maximum length give not the expected result of equality, and this is depending from the underlying database interface.

I was forced to eliminate almost all char columns in the application. I know the advantages of varchar or text columns.

To my knowledge, Oracle has the same semantics as Mysql and Postgres, which is to use all values as right trimmed strings in SQL expressions. 

To clarify, we should follow the whole paragraph from postgres documentation:
<citation>

Values of type character are physically padded with spaces to the specified width n, and are stored and displayed that way. However, trailing spaces are treated as semantically insignificant and disregarded when comparing two values of type character. In collations where whitespace is significant, this behavior can produce unexpected results, e.g. SELECT 'a '::CHAR(2) collate "C" < 'a\n'::CHAR(2) returns true. Trailing spaces are removed when converting a character value to one of the other string types. Note that trailing spaces are semantically significant in character varying and text values, and when using pattern matching, e.g. LIKE, regular expressions.

</citation>

There is no PG APIs to make CHAR work similar to how fe MySQL does. One thing is what is being done in the DB internally, the access API is something else. Also, in Postgres CHAR has absolutely no advantage over VARCHAR and others, rather the exact opposite.

It is barely acceptable to touch the data delivered from the database. Same way, if CHAR has now advantage in Postgres, probably it makes no sense to push for that datatype just because of MySQL handles it differently.

Thanks.