> -----Original Message-----
> From: Ann Harrison [mailto:harrison@...]
> Sent: Martes 7 de Noviembre de 2000 10:59
>
> I am considering making a short term change to the way
> the sub_type field is used on numeric datatypes. The
> change would define a sub_type of 0 or NULL as the native
> type (short, int, int64, float, double). Sub_type 1
> indicates that the column was defined as decimal. Sub_type
> 2 indicates that the column was defined as numeric.

RDB$FIELD_SUB_TYPE; SMALLINT; used to distinguish types of Blobs, CHARs, and
integers.
- 1 If RDB$FIELD_TYPE is 261 (Blob), predefined
subtypes can be:
• 0 - unspecified
• 1 - text
• 2 - BLR (Binary Language Representation)
• 3 - access control list
• 4 - reserved for future use
• 5 - encoded description of a table’s current
metadata
• 6 - description of multi-database transaction
that finished irregularly
- 2 If RDB$FIELD_TYPE is 14 (CHAR ), columns can
be:
• 0 - type is unspecified
• 1 - fixed BINARY data
Corresponds to the RDB$FIELD_SUB_TYPE
column in the RDB$COLLATIONS table
- 3 If RDB$FIELD_TYPE is 7 (SMALLINT), 8 (INTEGER),
or 16 (INT64), the original declaration was:
•0 or NULL - RDB$FIELD_TYPE
•1 - NUMERIC
•2 - DECIMAL
What's new on town, Mom? The current schema doesn't include float/double as
I don't see why they should be included... maybe for dialect 1? Clearly, in
dialect 3 they will never be used to support numeric or decimal.
But probably you will want to fix some problems that arise actually when
the time to display metadata programmatically comes:
- Some sub_types shown above aren't documented in rdb$types. This turns a
naive join on system tables to display metadata into an horror history.
- Int64 is not documented as a type in rdb$types.

> When we make an ODS change, I'd like to add a column to
> rdb$fields called rdb$precision, to hold, (surprise) the
> defined precision. That will involve extending dyn and
> a few other things.

Already done:
RDB$FIELD_PRECISION; SMALLINT; stores the precision for numeric and decimal
types.
Beware that this field can give you surprises: if you backup an ODS8/ODS9
database and restore it as ODS10, this field will come as NULL for the
metadata that already exists.
But precision is not enforced on data input. I mean, for example:
numeric(12,0) accepts a value that MsSQL only would accept if the field was
defined as numeric(19,0) instead.

Now that Charlie has popped up in the list, I would like to ask:
About rdb$function_arguments, this is explained:
RDB$MECHANISM; SMALLINT; specifies whether the argument is passed by value
(value of 0) or by reference (value of 1).
Well, by reading rdb$types, it's clear that more types (undocumented) exist
but also, there's a value that's not documented and doesn't appear in
rdb$types, too: when a UDF uses a return value with FREE_IT, the mechanism
for such "output argument" (typical "by value" or "by ref") is none of the
ones explained or defined in rdb$types but -1. Whether this is an oversight
or an intended singularity of metadata is what I want to know.

C.