Edit report at https://bugs.php.net/bug.php?id=46408&edit=1
ID: 46408
Updated by: yohg...@php.net
Reported by: alec at smecher dot bc dot ca
Summary: Locale number format settings can cause
pg_query_params to break with numerics
Status: Wont fix
Type: Bug
Package: PostgreSQL related
Operating System: *
PHP Version: 5.*, 6
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
>PostgreSQL is hard-coded to parse numeric values using "." as the decimal
>point
(see
>https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.
>c in set_var_from_str for implementation).
The number *may* be a string, what we should do then?
Is it "3.5" or "3,5"? Only the PHP programmer who is writing the code knew
which
should be. Therefore, this won't fix.
Previous Comments:
------------------------------------------------------------------------
[2012-04-17 19:52:49] alec at smecher dot bc dot ca
PostgreSQL is hard-coded to parse numeric values using "." as the decimal point
(see
https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/numeric.c
in set_var_from_str for implementation).
This agrees with the SQL92 grammar for a numeric literal:
http://savage.net.au/SQL/sql-92.bnf.html#exact%20numeric%20literal
...so by my reading PHP needs fixing.
------------------------------------------------------------------------
[2012-04-17 19:33:10] yohg...@php.net
I've tried different locale see if it works and it doesn't.
I also found this
http://www.postgresql.org/docs/8.4/static/locale.html
So , cannot replaced by .
There is other case transparent usage is not allowed. Money is one of them.
http://www.postgresql.org/docs/8.4/static/datatype-money.html
If postgres is going to support conversion, then it is going to work, since it
requires server side settings to work. (i.e. Database initialization, table
definition) It is not a bug or feature that should be fixed in PHP.
It's possible to do locale conversion in module, it would not be a good idea in
general.
------------------------------------------------------------------------
[2012-04-17 16:22:31] alec at smecher dot bc dot ca
yohgaki, I'm not sure I'm following, but to be clear: the bug entry is not
about whether the output is 3,5 or 3.5. The bug is that PostgreSQL throws a
syntax error when passing a floating-point number into a parameterized query.
See RhodiumToad's quoted comment.
You're quoting the following psql query:
select 123456789.12345::text::numeric;
What I'm trying to point out is this:
select 123456789,12345::text::numeric;
------------------------------------------------------------------------
[2012-04-17 08:21:43] yohg...@php.net
It seems it does not work that way.
http://www.postgresql.org/docs/8.4/static/locale.html
Check that PostgreSQL is actually using the locale that you think it is. The
LC_COLLATE and LC_CTYPE settings are determined when a database is created, and
cannot be changed except by creating a new database. Other locale settings
including LC_MESSAGES and LC_MONETARY are initially determined by the
environment the server is started in, but can be changed on-the-fly. You can
check the active locale settings using the SHOW command.
You may get currency as your locale setting, but not numbers.
yohgaki@[local] ~=# select 123456789.12345::text::money;
money
--------------------------
EUR12.345.678.912.345,00
yohgaki@[local] ~=# select 123456789.12345::text::numeric;
numeric
-----------------
123456789.12345
PHP's pgsql is getting all data as string. If there is a method that returns
numbers as you expected, then you'll get your outputs needed. Can do that in
PHP.
------------------------------------------------------------------------
[2012-03-31 05:43:17] yohg...@php.net
I guess setting locale to database locale resolve this issue.
------------------------------------------------------------------------
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=46408
--
Edit this bug report at https://bugs.php.net/bug.php?id=46408&edit=1
