Req #68156 [Asn->Opn]: pg_query_params Sets Boolean False to Blank String

Edit report at https://bugs.php.net/bug.php?id=68156&edit=1 ID: 68156 Updated by: kalle@php.net Reported by: nexisentertainment at gmail dot com Summary: pg_query_params Sets Boolean False to Blank String -Status: Assigned +Status: Open Type: Feature/Change Request Package: PostgreSQL related Operating System: Debian Linux (Jessie) PHP Version: 5.6.1 -Assigned To: yohgaki +Assigned To: Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2015-03-21 17:21:16] ianbytchek at gmail dot com 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. ------------------------------------------------------------------------ [2014-10-21 06:52:08] yohgaki@php.net 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. ------------------------------------------------------------------------ [2014-10-21 06:41:20] yohgaki@php.net 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)); } ------------------------------------------------------------------------ [2014-10-21 03:32:20] nexisentertainment at gmail dot com 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. ------------------------------------------------------------------------ [2014-10-19 02:43:52] yohgaki@php.net 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=68156 -- Edit this bug report at https://bugs.php.net/bug.php?id=68156&edit=1