Hello.

There also should be complementary addition of precision to XSQLVAR
structure:
short sqlprecision;

And good idea of using subtypes for VARCHAR and CHAR fields that can
indicate short binary data. This enables new data type aliases: VARBINARY(n)
and BINARY(n) (someone asked about octet(4) for ip adresses?).
Unfortunately, this can introduce incompatibility when software that assumes
every VAR/CHAR is textual tries to convert it to text.

Aleksey

"Claudio Valderrama C." <cvalde@...> wrote in message
news:NBBBIHEHIBHDIPDPGEPGAEECEBAA.cvalde@......

> > -----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.
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>

_______________________________________________
Ib-architect mailing list
Ib-architect@...
http://mers.com/mailman/listinfo/ib-architect