Commented by: Sean Leyne (seanleyne)

Even if "100,234", for the sake of argument, is the correct/excepted result based on the regional/locale settings, the handling of NUMERIC should be the same as DOUBLE and FLOAT.

As a workaround, the formatting of numeric values can be changed from the default handling/format defined by the LANG setting, to change to a format which aligns with the v2.5 output (LC_NUMERIC=en_US.utf8) restore the original . See this link for details (https://help.ubuntu.com/community/Locale)

Commented by: @kattunga

Hi Leyne,

CAST conversions never relied on the locale, this is new for Firebird 3.0?
This is big thing, because this affect date, time and numeric conversions to and from strings.

Now we need to take care of write date literals in locale format?
That is not documented

Regards

Commented by: Damian Jose (rdj4634)

Thanks Sean Leyne.

Change the locale like you said and it worked. But it would not be bad that the cast do a function of locale ?.

If I run this query with the wrong locale can generate conversion error

SELECT CAST (CAST (CAST (100234 AS DOUBLE PRECISION) AS VARCHAR (100)) AS DOUBLE PRECISION)
FROM RDB$DATABASE

Commented by: @dyemanov

Can anyone else reproduce this issue? Because I use "ru_RU.UTF-8" locale and should also get the same result as Damian (with commas), but I see the expected result (with dots).

Commented by: @dyemanov

Conversion of NUMERIC always use an explicit '.' as radix character. Conversion of FLOAT/DOUBLE is really locale-specific (it uses snprintf() for formatting), but every program starts with the "C" locale (aka "POSIX" on Linux) which also uses '.' as radix character. Firebird does not use the locale defined in OS environment. This is why the conversion results are always consistent and never depend on the client's locale. The only difference between v2.5 and v3.0 is that v3.0 inherits the LC_CTYPE setting from the enviroment, to allow conversions between system charset and UTF8. But it should not affect the conversion result which is controlled by LC_NUMERIC (which is not inherited). So I honestly don't see how this issue could become possible at all.

Commented by: @AlexPeshkoff

Dmitry, there are funny lines in fbudf.cpp:

      // There should be a better way to do this than to alter the thread's locale\.
      if \(\!strcmp\(setlocale\(LC\_TIME, NULL\), "C"\)\)
            setlocale\(LC\_ALL, ""\);

And something like this can take place in other UDFs.
On the other hand if that is due to UDF it should cause same effect for 2.5.

Commented by: Damian Jose (rdj4634)

if it is helpful, but I use is Ubuntu 16.04 and compilation is the Firebird firebird-3.0.1.32525-0.amd64, this compilation is not release, use this compilation because the official firebird service is restarted when a udf own generated an error.

Commented by: Damian Jose (rdj4634)

One thing to take care about is that I'm using a daily snapshot build, Firebird firebird-3.0.1.32525-0.amd64. Could be something related to this compilation?
Another issue is the version of Ubuntu I'm using is 16.04, this version has some changes in initialization scripts, may be it's something related to that.

Commented by: @dyemanov

I'm also on 16.04 and I tried the current v3.0.1 checkout (self-made build though).

Commented by: @asfernandes

I do have LANG=pt_BR.UTF-8 (which would use comma for decimal separator too) and the result cast has dot as decimal separator.