php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #78855 Native PHP types in database fetches
Submitted: 2019-11-22 10:51 UTC Modified: -
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: olegxx at gmail dot com Assigned:
Status: Open Package: PostgreSQL related
PHP Version: 7.2.25 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: olegxx at gmail dot com
New email:
PHP Version: OS:

 

 [2019-11-22 10:51 UTC] olegxx at gmail dot com
Description:
------------
PostgreSQL extension should return native PHP types (int, bool, string) from database queries as pdo_pgsql does.

To maintain backward compatibility, we can add a new result type flag to pg_fetch_array and pg_fetch_all (e.g. PSQL_TYPED) or create new fetch function.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-11-22 11:03 UTC] olegxx at gmail dot com
Added pull request for the first variant:
https://github.com/php/php-src/pull/4939
 [2019-11-22 11:11 UTC] fgfgfgfdf at somewhere dot com
it's simply wrong add a param to each and every function and just to two can't be serious - how do you imagine to port existing code to that without a ton of errors over the time?

besides that another quick shot with mor incosntistences given that myqli has solved that years ago ina proper way

if(mysqli_options($this->conn, MYSQLI_OPT_INT_AND_FLOAT_NATIVE, TRUE) === FALSE)
{
 $this->error('mysqli_options(MYSQLI_OPT_INT_AND_FLOAT_NATIVE) failed');
}
 [2019-11-22 11:29 UTC] imbolk at gmail dot com
fgfgfgfdf, what about pg_fetch_result? It returns false on an error and will, in your case, return false also if it succeeds in getting the value false.
 [2019-11-22 11:35 UTC] fgfgfgfdf at somewhere dot com
didn't you get the point?

it has to be *connection wide* option and it shouldn't be completly different for each and every database type

mysqli_init() -> mysqli_options() -> mysqli_real_connect()
 [2019-11-22 12:14 UTC] olegxx at gmail dot com
This extension do not have any connection wide options.
The problem with pg_fetch_result is that it cannot return false as valid result because it return false is case of an error.
 [2019-11-22 12:19 UTC] imbolk at gmail dot com
Of course I understand that. I don't think you understand what I mean.

Now pg_fetch_result returns FALSE on the error. If they do as you suggest, it will return FALSE on the error and FALSE if it need to return the boolean value of FALSE, which came from the database.
 [2019-11-22 12:23 UTC] fgfgfgfdf at somewhere dot com
> This extension do not have any connection wide options

cool, than introduce pg_options() is the right thing to do for the sake of cosistency and usability

either i have a strict typed project or not and seek and adjust every single line containing pg_ don't scale at any moment, in a existing codebase nobody would do that and later you can be sure people forget to use the option here and there which is not funny when you get strings instead int on random places
 [2019-11-22 12:24 UTC] imbolk at gmail dot com
MySQL does not have a Boolean type, and Postgres does.
 [2019-11-22 12:27 UTC] olegxx at gmail dot com
PostgreSQL have bool type:

$res = pg_query($db, "SELECT false");
var_dump(pg_fetch_result($res, 0));

This code should print "bool(false)" in native types mode but
"FALSE is returned if row exceeds the number of rows in the set, or on any other error."
 [2019-11-22 12:28 UTC] fgfgfgfdf at somewhere dot com
> MySQL does not have a Boolean type, and Postgres does

and how is that relevant when it's about a global connection option versus add params to each and every single command which needs massive rewrite in existing userland code to use it?
 [2019-11-22 12:47 UTC] olegxx at gmail dot com
We can add extension wide (php.ini) option to change behavior of all fetch functions, also we can add fourth param to pg_fetch_result to return error in it for example.
 [2019-11-22 12:51 UTC] fgfgfgfdf at somewhere dot com
> We can add extension wide (php.ini) option to change
> behavior of all fetch functions

you can't, no RFC introducing ini options which change language behavior that way will pass in 2019

> also we can add fourth param to pg_fetch_result to return 
> error in it for example

or you can refrain from half thougth solutions and write a proper RFC which get discussed, no way that any change in that context will go into 7.2/7.3/7.4 anyways
 [2019-11-22 13:07 UTC] imbolk at gmail dot com
> and how is that relevant when it's about a global connection option versus add params to each and every single command which needs massive rewrite in existing userland code to use it?

Because the global option will also affect this function too. It is absolutely unclear how it should work in this case.
 [2022-11-29 05:34 UTC] fariba dot shami326 at gmail dot com
Thanks for the update and quick reply. I'll be sure to keep an eye on this thread.

(https://www.mymilestonecard.bid/)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 11:01:28 2024 UTC