#19 cursor.description -> precision always 0

closed-fixed
nobody
5
2002-06-09
2002-04-29
No

The 'precision' slot in cursor.description is always
0, even when it should be otherwise (in the case of
NUMERIC/DECIMAL fields, for example).

This is because the function XSQLDA2describe makes no
attempt to determine the precision, but always sets it
to zero.

Unfortunately, the precision is not easily gleaned
from the XSQLDVAR structure (as is scale, for
instance). Instead, it appears necessary to query the
system tables in order to determine the field's
precision.

It seems a shame to waste computational effort
querying the system tables when the 'precision' figure
in cursor.description will not usually even be used;
perhaps there's an alternative?

Discussion

  • marcin andrzejewski

    Logged In: YES
    user_id=537867

    not only precision, but also length of decimal and numeric fields is not
    returned as it should. so one has to query rdb$fields in order to get right
    values.

     
  • marcin andrzejewski

    Logged In: YES
    user_id=537867

    not only precision, but also length of decimal and numeric fields is not
    returned as it should. so one has to query rdb$fields in order to get right
    values.

     
  • David S. Rushby

    David S. Rushby - 2002-05-08

    Logged In: YES
    user_id=414645

    "not only precision, but also length of decimal and numeric
    fields is not returned as it should."

    I think we're referring to the same thing using different
    words ("precision"/"length"). NUMERIC fields are defined
    with the syntax

    NUMERIC[(precision [, scale])]

    , which makes the "length" of a NUMERIC the same as its
    "precision" (see the IB 6 Data Definition Guide page 64).
    (Of course all of this also applies to DECIMAL fields.)

    ---------------------------------

    Unlike the "precision" of a fixed decimal field, the "scale"
    *is* provided by the current implementation of kinterbasdb.
    The scale returned in the cursor.description by kinterbasdb
    is typically a negative value, though (e.g., in the case of
    NUMERIC(10, 2)). kinterbasdb's scale values follow
    Interbase conventions, and the Python DB API spec doesn't
    make it clear whether the scale should be positive or
    negative in a case such as the example above. This will
    requires some investigation.

    ---------------------------------

    The fix for bug #549982 (this bug) is no mystery; I've just
    been dallying while I tried to find a faster solution than
    running a separate query against the system tables for
    *every output column of every ordinary query*.

    Of course, I can settle for the slow solution at first and
    then replace it with a faster implementation if one is
    discovered. So I'll commit a fix for this bug to CVS in the
    next few days.

     
  • David S. Rushby

    David S. Rushby - 2002-05-12

    Logged In: YES
    user_id=414645

    Fixed in CVS revision 1.25 of _kinterbasdb.c

     
  • David S. Rushby

    David S. Rushby - 2002-05-12
    • status: open --> closed-fixed
     
  • David S. Rushby

    David S. Rushby - 2002-05-16
    • status: closed-fixed --> open-fixed
     
  • David S. Rushby

    David S. Rushby - 2002-05-16

    Logged In: YES
    user_id=414645

    This is somewhat more complex than I originally thought.

    In addition to ordinary table fields, which present no
    problem, special cases must exist to handle dynamically
    computed fields (e.g., SELECT x/2 FROM TBL), stored
    procedure output parameters, and view "fields" (with
    differences depending on what sort of query underlies the view).

    It won't be realistically possible to determine field
    precision in every one of these cases, but I'll handle those
    which I reasonably can.

    In the meantime, beware that CVS revisions 1.25 and 1.26 of
    _kinterbasdb.c are incomplete and will not function properly.

     
  • David S. Rushby

    David S. Rushby - 2002-06-09

    Logged In: YES
    user_id=414645

    In CVS rev 1.27 of _kinterbasdb.c, the bugfix handles the
    extended cases mentioned below (table, view, stored
    procedure, dynamically computed field).

     
  • David S. Rushby

    David S. Rushby - 2002-06-09
    • status: open-fixed --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks