I'd be interested to know what the Oracle ODBC driver returns for
various forms of Oracle NUMBER and happiest to do the same in DBD::Oracle.
Tim.
On Thu, Mar 22, 2001 at 02:45:01PM +0100, Steffen Goeldner wrote:
> Our applications heavy rely on metadata. Unfortunately,
> we encountered a problem with numeric datatypes.
> For an Oracle NUMBER, the following statement handle
> attributes are returned:
>
> TYPE 3 (NUMBER)
> PRECISION 38
> SCALE 0
>
> The same attributes are returned for NUMBER( 38, 0 ).
> We found the relevant code in oci8.c, line 707:
>
> case 2: /* NUMBER */
> if (!fbh->prec) /* is 0 for FLOATing point */
> fbh->prec = 38; /* max prec */
> fbh->disize = 130+3; /* worst case! 1**-130 */
> avg_width = 4; /* > approx +/- 1_000_000 ? */
> break;
>
> and in oci7.c, line 243:
>
> else if (fbh->dbtype == 2 && fbh->prec == 0) {
> fbh->prec = 38;
> }
>
> The question is: What should be returned for a NUMBER?
> We collected some alternatives:
>
> # TYPE PREC SCALE Remarks
> - ---- ----- -----
> ------------------------------------------------------
> 1 3 38 0 the current solution, ambiguous!
> 2 3 0 0 the Oracle way
> 3 3 38 undef better, but possible confusion with NUMBER(38)
> 4 6 126 undef FLOAT, binary precision
> 5 6 undef undef FLOAT, default prec. is 126 binary in Oracle
> 6 8 126 undef DOUBLE PRECISION, binary precision
> 7 8 undef undef DOUBLE PRECISION, prec. is always 126 binary in
> Oracle
>
> Our favourite solution is #6, if the driver should reflect the standard.
> However, if the driver should support vendor specific peculiarities,
> #2 is the way to go.
> We expect, that the patches are simple. However, we don't know
> how to provide the 'undef'. Is
>
> fbh->scale = PL_sv_undef;
>
> the correct way?
>
> BTW: Cases 4 and 5 (FLOAT) show, that the type_info LoL is incomplete.
> Also note, that type_info defines a COLUMN_SIZE of 15 for DOUBLE.
>
>
> Steffen Gldner
> Olga Voronova
