Hi all,
On Wed, Sep 19, 2012 at 8:35 PM, Lars Strojny<l...@strojny.net> wrote:
> I'm currently working onhttps://github.com/php/php-src/pull/186, which fixes
a \
> problem with PostgreSQL when passing a float to pg_query_params() with a
locale \
> setting that uses "," as a decimal point. pg_query_params() uses \
> convert_to_string(), which uses %G as a format string for floats, which is
locale \
> sensitive (and therefore converts e.g. in hr_HR or de_DE to "1,1"). The
proposed \
> fix is to introduce a new API convert_to_cstring() in the Zend Engine to
allow \
> converting types to C-locale strings.
> This kind of fix is very likely needed in other places, where floats are
converted \
> using convert_to_string(). I haven’t found time to try e.g. mysqlnd, but I
suspect \
> we’ll find similar issues there. I don’t think the proposed workaround of
burden \
> users with explicitly converting floats to a numeric representation is a
good \
> solution and I think we should fix bugs like that in places they occur.
> What’s your take on the proposed fix of introducing convert_to_cstring() and
using \
> it where external protocols require a locale insensitive float conversion?
To me it looks like it is not something we should try to solve. The
application, database code (via connection options, queries, etc.)
should take care of.
I originally posted the bug at <https://bugs.php.net/bug.php?id=46408>
and sent the pull request. (Thanks for your help so far, Lars.) I'm not
very aware of the implications of a broader fix; my concern is
specifically with pg_query_params function.
Consider the use case:
pg_query_params($conn, 'INSERT INTO myTable (myColumn) values ($1)',
array(3.5));
If your locale is e.g. hr_HR, this will result in a syntax error because
the number will be converted into "3,5" and thus an invalid number for
SQL's purposes.
You might point out that myColumn could be a varchar, but I would argue
that in that case the calling code should convert explicitly:
pg_query_params($conn, 'INSERT INTO myTable (myColumn) values ($1)',
array("3.5"));
This (storing numeric data in varchars) is a much less common use case IMO.
It looks to me like a textbook use case of pg_query_params will
currently fail depending on what locale is being used. What Claude at
<https://bugs.php.net/bug.php?id=46408#1334753071> and Lars here are
trying to do is make it a general fix, which is good -- but the problem
is best exemplified IMO by the above snippet. The work-around suggested
by j...@php.net (https://bugs.php.net/bug.php?id=46408#1227272959)
illustrates further:
$oldLocale = setlocale(LC_NUMERIC, 'C');
pg_query_params($conn, 'INSERT INTO myTable (myColumn) values ($1)',
array(3.5));
setlocale(LC_NUMERIC, $oldLocale);
That's an example of a work-around for a broken API in my opinion.
Thanks,
Alec
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
