Req #68156 [Com]: pg_query_params Sets Boolean False to Blank String

From: Date: Tue, 21 Oct 2014 06:52:09 +0000
Subject: Req #68156 [Com]: pg_query_params Sets Boolean False to Blank String
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-188220@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68156&edit=1 ID: 68156 Comment by: yohgaki@php.net 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2014-10-05 07:50:48] nexisentertainment at gmail dot com Should be more clear. ------------------------------------------------------------------------ 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

« previous php.bugs (#188220) next »