Edit report at https://bugs.php.net/bug.php?id=68156&edit=1
ID: 68156
Comment by: ianbytchek at gmail dot com
Reported by: nexisentertainment at gmail dot com
Summary: pg_query_params Sets Boolean False to Blank String
Status: Assigned
Type: Feature/Change Request
Package: PostgreSQL related
Operating System: Debian Linux (Jessie)
PHP Version: 5.6.1
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2014-10-05 09:30:00] nexisentertainment at gmail dot com
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.
------------------------------------------------------------------------
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