php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69590 OCI extension: oci_field_scale returns 0 for float expression
Submitted: 2015-05-07 06:55 UTC Modified: 2015-05-07 18:21 UTC
From: vavra at 602 dot cz Assigned: sixd (profile)
Status: Not a bug Package: OCI8 related
PHP Version: 5.6.8 OS: Windows7 32bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: vavra at 602 dot cz
New email:
PHP Version: OS:

 

 [2015-05-07 06:55 UTC] vavra at 602 dot cz
Description:
------------
Lets consider this table
 create table test_division(a number, b number);
with values
 insert into test_division values (21, 2);  
and this query
 select a, b, a/b division, 21/2 constant_division from test_division
leads to result in our system
{
  'A' =>
  double(21)
  'B' =>
  double(2)
  'DIVISION' =>
  int(10)
  'CONSTANT_DIVISION' =>
  double(10.5)
}

The problem is that oci_field_scale(., 'DIVISION') returns 0. (Note: for 'CONSTANT_DIVISION' returns -127). In our system we decide according to the oci_field_scale result, if to call intval or floatval on column value. OCI driver returns always string values and we need to convert them.

Oracle version is Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production, Windows.

Expected result:
----------------
oci_field_scale(., 'DIVISION') should return 1, or -127 (as says documentation: For FLOAT columns, precision is nonzero and scale is -127.)

Actual result:
--------------
0

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-05-07 18:16 UTC] sixd@php.net
-Status: Open +Status: Not a bug -Package: *General Issues +Package: OCI8 related -Assigned To: +Assigned To: sixd
 [2015-05-07 18:16 UTC] sixd@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

- This isn't specific to PHP.  Try 'CREATE TABLE testtab as select a, b, a/b division, 21/2 constant_division from test_division' and change your PHP code to query testtab. You will see the same result.

- The columns are of type NUMBER.  Check oci_field_precision(). It is zero in all cases.  From Table 6-8 in the OCI manual https://docs.oracle.com/database/121/LNOCI/oci06des.htm#LNOCI16458 it says "When precision is 0, NUMBER(precision, scale) can be represented simply as NUMBER."

- It seems a semi-interesting quirk that the runtime/compile time evaluation is returning different scales.
 [2015-05-07 18:21 UTC] sixd@php.net
By 'same results', I mean precision is always 0 so the rule I quoted applies.
 [2015-05-11 10:36 UTC] vavra at 602 dot cz
Shall I understand this that this is OCI (Oracle) bug and I should create a new issue for Oracle?

You are quoting "When precision is 0, NUMBER(precision, scale) can be represented simply as NUMBER."

Well, when the NUMBER is without precision, the Oracle doc says: "The absence of precision and scale designators specifies the maximum range and
precision for an Oracle number." So the operands are floats.

Even if the operands would have been integers (NUMBER(x)), the division should result to oci_field_scale(.) with nonzero. And I got the same bad result 0 for table with integers with same values as above:
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 02:01:30 2024 UTC