Subject Re: [Firebird-Java] Re: Only real types in FBDatabaseMetaData.getTypeInfo
Author Blas Rodriguez Somoza
Hello David

> > There are two problems in the mapping.
> >
> > The first problem is that the typeInfo serves to map SQL types to
> > java.sql.Types, and can be many to one but not one to many.
> > Each SQL type must have a row in the table and only one.
> Is this in the spec?
The api docs about getTypeInfo begins with
Retrieves a description of all the standard SQL types supported by this database
In this sentence the word standard is usually readed as DB standard SQL types and not SQL-92/99 etc standard types.

> I looked in my sql reference, and apparently I made a mistake, confusing
> NUMERIC and DECIMAL. NUMERIC requires exact precision, DECIMAL allows
> greater precision than that requested. I haven't checked yet to verify
> that Long.MAX_VALUE can be stored in DECIMAL(18.0) but it is at least
> allowed by the sql spec.
In firebird, BIGINT values can be stored on decimal or numeric fields, but only because Firebird does not enforce precision,
something that I expect will change in the future.

Let me add another problem your change creates, in the metadata of a table the driver can't know if a numeric/decimal(18,0) column
is a generic numeric that maps to numeric, or numeric(18,0) that maps to BIGINT, so the DatabaseMetaData.getTypeInfo() don't agree
with databaseMetaData.getColumns() and resultSet.getTypeName() when the type used is NUMERIC(18,0). There are two types in
getTypeInfo that only maps to one in the table/resultSet metadata, so the metaData implementation is broken.

Because the discussion about standards could take a long time and be useless, let take another direction to try to solve this
question ASAP.

The fact is I expend a lot of time to implement standard things in the meta data information (not everything they ask for) those
guys need, your change break the implementation, and I think you don't need it. Also if you need this mapping for your own purposes
you can maintain it outside the CVS.

I'm working now to make the driver version/dialect aware, when I finish with that I will add the BIGINT type and then you will get
the BIGINT for your trials.

Actually, the driver is buggy for dialect 1 or 2 because it does not take into account the db version or dialect when it is needed.
There are several places where the dialect must be taken into account mainly in the metadata. For instance the typeInfo version must
take into account the db version, for dialect 1 and 2 the max precision for NUMERIC and DECIMAL is 10 whether for dialect 3 is 18.

Please, can you agree with that and remove the mapping from CVS?.

Blas Rodriguez Somoza