|Subject||RE: [IB-Architect] System table change|
|Author||Claudio Valderrama C.|
> -----Original Message-----RDB$FIELD_SUB_TYPE; SMALLINT; used to distinguish types of Blobs, CHARs, and
> 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.
- 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 tables current
6 - description of multi-database transaction
that finished irregularly
- 2 If RDB$FIELD_TYPE is 14 (CHAR ), columns can
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 toAlready done:
> rdb$fields called rdb$precision, to hold, (surprise) the
> defined precision. That will involve extending dyn and
> a few other things.
RDB$FIELD_PRECISION; SMALLINT; stores the precision for numeric and decimal
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.