Should be more clear.

Created a simplified test phpt.  Used it to verify the issue still exists on git (commit 429e1b45a7cd2f491e836f4bffa57c72beb6128b).

https://gist.github.com/N3X15/56ab6238a5a8e57bdc32

Can link if someone hates gists.  Will now attempt to sleep.

IIRC, PostgreSQL does not support true/false since 6.x.
http://www.postgresql.org/docs/9.3/static/datatype-boolean.html

Valid literal values for the "true" state are:

TRUE
't'
'true'
'y'
'yes'
'on'
'1'For the "false" state, the following values can be used:
FALSE
'f'
'false'
'n'
'no'
'off'
'0'

So, this behavior is not a bug. It could be feature request.

I don't understand how unexpected behavior is not a bug.  There's no note in the documentation about this, and it's heavily implied that the values will be converted to the correct SQL types rather than simply converted to strings and thrown into the query.  In fact, the only notice about this is from a user in the comments.

In any case, '' is NOT a valid literal for false in Postgres.

With prepared query type query, NULL must be handled special way. Therefore, NULL is treated specially. Implicit type conversion for database is evil, since database fields could have much higher precisions.

Except NULL, any values are simply converted to string including bool. ('1' or '').

Bool could be treated specially like NULL, but it's BC. Thus, it's a feature request.

		for(i = 0; i < num_params; i++) {
			if (zend_hash_get_current_data(Z_ARRVAL_P(pv_param_arr), (void **) &tmp) == FAILURE) {
				php_error_docref(NULL TSRMLS_CC, E_WARNING,"Error getting parameter");
				_php_pgsql_free_params(params, num_params);
				RETURN_FALSE;
			}

			if (Z_TYPE_PP(tmp) == IS_NULL) {
				params[i] = NULL;
			} else {
				zval tmp_val = **tmp;
				zval_copy_ctor(&tmp_val);
				convert_to_cstring(&tmp_val);
				if (Z_TYPE(tmp_val) != IS_STRING) {
					php_error_docref(NULL TSRMLS_CC, E_WARNING,"Error converting parameter");
					zval_dtor(&tmp_val);
					_php_pgsql_free_params(params, num_params);
					RETURN_FALSE;
				}
				params[i] = estrndup(Z_STRVAL(tmp_val), Z_STRLEN(tmp_val));
				zval_dtor(&tmp_val);
			}

			zend_hash_move_forward(Z_ARRVAL_P(pv_param_arr));
		}

There is similar feature/change request. I might be able to write a RFC for more seamless bool handling for next PHP, but I cannot promise.

The same behaviour in PDO. Unless I'm badly confusing this with something else Postgre has boolean type which accepts TRUE/FALSE values. I've read the comments and understand why it works this way, but that would be really good if we didn't have to treat booleans in any special way, like we don't treat nulls. `TRUE` and `FALSE` in postgre have the exact same meaning and purpose as `true` and `false` in php. More to that, when we load data from postgre, we don't get string or integer representations for booleans, we actually get proper booleans, which makes things inconsistent, e.g., if I load and try to save the same data I will get an error.