Values in RDB$FIELDS.RDB$FIELD_SUB_TYPE for textual datatypes

Pavel Zotov

unread,

Jul 11, 2026, 5:47:41 PMJul 11

to firebird-devel

Consider script:

============

create view v_fields_info as
select
rf.rdb$field_name as rf_fld_name
,f.rdb$field_type as f_field_type
,f.rdb$field_sub_type as f_fld_sub_type
,f.rdb$segment_length as f_segm_len
from rdb$relation_fields rf
join rdb$fields f on rf.rdb$field_source = f.rdb$field_name
where rf.rdb$relation_name = coalesce( rdb$get_context('USER_SESSION','DEBUG_REL_NAME'), upper('TEST'))
order by rf.rdb$field_position
;

recreate table test (
tbin binary(1)
,vbin varbinary(1)
,bbin blob sub_type binary segment size 512 not null
,comp_tbin computed by ( tbin )
,comp_vbin computed by ( vbin )
,comp_bbin computed by ( bbin )

,tchr char(1)
,vchr varchar(1)
,bchr blob sub_type text segment size 2048 character set win1250 not null collate win_cz
,comp_tchr computed by ( tchr )
,comp_vchr computed by ( vchr )
,comp_bchr computed by ( bchr )

);

show table test;
commit;
set width RF_FLD_NAME 12;
select * from v_fields_info;

============

On 4.x ... 6.x its output will be the same.

Some data remain unclear for me:

Q1. Value of RDB$FIELDS.RDB$FIELD_SUB_TYPE (in some rows, see them below marked as "????") - when it should be 1 or 0 ?

Q2. Should the value of rdb$segment_length be 'propagated'from blob to computed column that is based on this blob ?

============

TBIN BINARY(1) Nullable
VBIN VARBINARY(1) Nullable
BBIN BLOB segment 512, subtype BINARY Not Null
COMP_TBIN Computed by: ( tbin )
COMP_VBIN Computed by: ( vbin )
COMP_BBIN Computed by: ( bbin )
TCHR CHAR(1) Nullable
VCHR VARCHAR(1) Nullable
BCHR BLOB segment 2048, subtype TEXT CHARACTER SET WIN1250 Not Null
COLLATE WIN_CZ
COMP_TCHR Computed by: ( tchr )
COMP_VCHR Computed by: ( vchr )
COMP_BCHR Computed by: ( bchr )

14 - char
37 - varchar
261 - blob

RF_FLD_NAME F_FIELD_TYPE F_FLD_SUB_TYPE F_SEGM_LEN|
============ ============ ============== ==========|
TBIN 14 1 | [OK] // BINARY(1) ==> ~ "for the CHAR ... fixed binary data" ?
VBIN 37 1 | ???? // VARBINARY(1) = varchar(1) char set octets
BBIN 261 0 512| [OK] // BLOB subtype BINARY ==> ~ "for the BLOB ... untyped (binary)"
COMP_TBIN 14 0 | ???? // computed by: ( BINARY(1) )
COMP_VBIN 37 0 | ???? // computed by: ( VARBINARY(1) )
COMP_BBIN 261 0 ? | seg? // computed by ( BLOB segment 512 subtype BINARY ) ==> ~ "for the BLOB ... untyped (binary)"
TCHR 14 0 | ???? // CHAR(1)
VCHR 37 0 | ???? // VARCHAR(1)
BCHR 261 1 2048| [OK] // BLOB ... subtype TEXT CHARACTER SET WIN1250
COMP_TCHR 14 0 | ???? // computed by ( CHAR(1) )
COMP_VCHR 37 0 | ???? // computed by ( VARCHAR(1) )
COMP_BCHR 261 1 ? | seg? // computed by ( BLOB segment 2048 subtype TEXT CHARACTER SET WIN1250 )============

PS.

The column RDB$FIELDS. RDB$FIELD_SUB_TYPE is described in the doc as:

=============

Specifies the subtype for the BLOB data type:
0 - untyped (binary)
1 - text
Specifies for the CHAR data type:
0 - untyped data
1 - fixed binary data

=============

What means " untyped" in the doc for Character type ?

Mark Rotteveel

unread,

Jul 12, 2026, 4:11:53 AMJul 12

to firebir...@googlegroups.com

On 11-07-2026 23:47, Pavel Zotov wrote:
> On 4.x ... 6.x its output will be the same.
> Some data remain unclear for me:
> Q1. Value of RDB$FIELDS.RDB$FIELD_SUB_TYPE (in some rows, see them below
> marked as "????") - when it should be 1 or 0 ?

See comments inline below.

> Q2. Should the value of rdb$segment_lengthbe 'propagated'from blob to

> computed column that is based on this blob ?

Given segment lengths are just a holdover from the past, and should
never be relevant these days (except maybe in some ESQL cases?), I don't
think it's that important to change.

Also, computed columns where the expression is just another column
reference are rather artificial, which segment size should it choose if
there is a more complex expression, possibly involving multiple blob
columns with different segment sizes? If someone really still cares
about segment sizes, they should specify the data type, including
segment size, explicitly.

> ============
> TBIN BINARY(1) Nullable
> VBIN VARBINARY(1) Nullable
> BBIN BLOB segment 512, subtype BINARY Not Null
> COMP_TBIN Computed by: ( tbin )
> COMP_VBIN Computed by: ( vbin )
> COMP_BBIN Computed by: ( bbin )
> TCHR CHAR(1) Nullable
> VCHR VARCHAR(1) Nullable
> BCHR BLOB segment 2048, subtype TEXT
> CHARACTER SET WIN1250 Not Null
> COLLATE WIN_CZ
> COMP_TCHR Computed by: ( tchr )
> COMP_VCHR Computed by: ( vchr )
> COMP_BCHR Computed by: ( bchr )
>
> 14 - char
> 37 - varchar
> 261 - blob
>
> RF_FLD_NAME F_FIELD_TYPE F_FLD_SUB_TYPE F_SEGM_LEN|
> ============ ============ ============== ==========|
> TBIN 14 1 | [OK] // BINARY(1)
> ==> ~ "for the CHAR ... fixed binary data" ?
> VBIN 37 1 | ???? //
> VARBINARY(1) = varchar(1) char set octets

Why the ??? a VARBINARY is a VARCHAR with subtype 1, just like BINARY is
a CHAR with subtype 1.

> BBIN 261 0 512| [OK] // BLOB
> subtype BINARY ==> ~ "for the BLOB ... untyped (binary)"
> COMP_TBIN 14 0 | ???? // computed
> by: ( BINARY(1) )
> COMP_VBIN 37 0 | ???? // computed
> by: ( VARBINARY(1) )

Sounds like a bug in the type derivation, losing the subtype. This is
not unheard of, I think it also happens (or happened, I haven't checked
now) with computed columns involving NUMERIC and DECIMAL.

On the other hand, just like mentioned before, this is a rather
artificial case, having an expression that is just a column reference as
a computed column.

> COMP_BBIN 261 0 ? | seg? // computed by
> ( BLOB segment 512 subtype BINARY ) ==> ~ "for the BLOB ... untyped
> (binary)"
> TCHR 14 0 | ???? // CHAR(1)
> VCHR 37 0 | ???? // VARCHAR(1)

Why ??? for CHAR and VARCHAR, subtype 0 means its CHAR/VARCHAR, and not
BINARY/VARBINARY

> BCHR 261 1 2048| [OK] // BLOB ...
> subtype TEXT CHARACTER SET WIN1250
> COMP_TCHR 14 0 | ???? // computed by
> ( CHAR(1) )
> COMP_VCHR 37 0 | ???? // computed by
> ( VARCHAR(1) )

Again, why the ??? (though it could theoretically be losing the subtype
information, just like the earlier example).

> PS.
> The column RDB$FIELDS. RDB$FIELD_SUB_TYPE <https://
> www.firebirdsql.org/file/documentation/html/en/refdocs/fblangref50/
> firebird-50-language-reference.html#fblangref-appx04-fields> is

> described in the doc as:
> =============
> Specifies the subtype for the BLOB data type:
> 0 - untyped (binary)
> 1 - text
> Specifies for the CHAR data type:

> 0 - *untyped* data
> 1 - fixed *binary* data

> =============
> What means " untyped" in the doc for Character type ?

Untyped means it's just a plain CHAR/VARCHAR and doesn't have a more
specific type like BINARY/VARBINARY. However, I'll see if I can rephrase
or clarify it.

The fact it says "CHAR data type" instead of "character data type" or
"CHAR/VARCHAR data type" is an error on my part. I guess when I started
writing it, I wanted to list CHAR and VARCHAR separately, and then
changed my mind. The word binary means it's binary data, not
specifically the BINARY datatype (typography matters here). That "fixed"
probably needs to go as well.

Mark
--
Mark Rotteveel

Mark Rotteveel

unread,

Jul 12, 2026, 4:28:46 AMJul 12

to firebir...@googlegroups.com

On 11-07-2026 23:47, Pavel Zotov wrote:

> RF_FLD_NAME F_FIELD_TYPE F_FLD_SUB_TYPE F_SEGM_LEN|
> ============ ============ ============== ==========|

...

> VBIN 37 1 | ???? //
> VARBINARY(1) = varchar(1) char set octets

This is an incorrect assumption on your part. If you had used VARCHAR(1)
CHARACTER SET OCTETS instead of VARBINARY, the column definition would
have had subtype 0, so VARBINARY is not identical to VARCHAR(1)
CHARACTER SET OCTETS *when it comes to its metadata*.

Behaviourally, (VAR)BINARY is identical to (VAR)CHAR CHARACTER SET
OCTETS, and some APIs will report them identically, because in some
parts of the API, the character set and collation are reported as
subtype for the character data types. Subtype 1 is used because
character set OCTETS is character set id 1, not because 1 was the next
available subtype.

Mark
--
Mark Rotteveel

Mark Rotteveel

unread,

Jul 12, 2026, 4:42:22 AMJul 12

to firebir...@googlegroups.com

On 12-07-2026 10:11, 'Mark Rotteveel' via firebird-devel wrote:
> I guess when I started
> writing it, I wanted to list CHAR and VARCHAR separately, and then
> changed my mind.

Correction, this was already listed in the InterBase 6 Language
Reference (page 251 of the PDF), and through that also ended up in our
language references. It seems to refer to functionality that didn't
actually exist (as it mentions "Corresponds to the RDB$FIELD_SUB_TYPE
column in the RDB$COLLATIONS table", but no such column exists (nor
existed back then).

Mark
--
Mark Rotteveel

Pavel Zotov

unread,

Jul 12, 2026, 7:11:18 AMJul 12

to firebird-devel

On Sunday, July 12, 2026 at 11:11:53 AM UTC+3 Mark Rotteveel wrote:

> 14 - char
> 37 - varchar
> 261 - blob
>
> RF_FLD_NAME F_FIELD_TYPE F_FLD_SUB_TYPE F_SEGM_LEN|
> ============ ============ ============== ==========|
> TBIN 14 1 | [OK] // BINARY(1)
> ==> ~ "for the CHAR ... fixed binary data" ?
> VBIN 37 1 | ???? //
> VARBINARY(1) = varchar(1) char set octets

Why the ??? a VARBINARY is a VARCHAR with subtype 1, just like BINARY is
a CHAR with subtype 1.

I was confuced by word "fixed" (from doc: "1 - fixed binary data") because in my mind this meant fixed length :-)

> BBIN 261 0 512| [OK] // BLOB
> subtype BINARY ==> ~ "for the BLOB ... untyped (binary)"
> COMP_TBIN 14 0 | ???? // computed
> by: ( BINARY(1) )
> COMP_VBIN 37 0 | ???? // computed
> by: ( VARBINARY(1) )

Sounds like a bug in the type derivation, losing the subtype. This is
not unheard of, I think it also happens (or happened, I haven't checked
now) with computed columns involving NUMERIC and DECIMAL.

i could not find any note in the doc what values must be assigned to rdb$field_type & rdb$field_sub_type for COMPUTED column if it is based on integer (numeric) column.

Outcome of similar script (slightly modified from original post, see it below) show that:

* when base column type belongs to smallint, int or bigint then computed column will have field_type = 16 and sub_type = 0 (i.e. this is BIGINT);

* when base type is int128 then computed column will have same type (field_type = 26 and sub_type = 0);

* for base type beloging to numeric and decimal types with up to 18 digits - computed column will be either numeric(18) or decimal(18); otherwise - numeric(38) or decimal(38). NOTE: sub_type differs for such computed columns thus we able to distinguish them;

* for base type = float or double precision computed column will have double precision;

* for base type = decfloat(16) or decfloat(34) computed column will have decfloat(34).

...

> TCHR 14 0 | ???? // CHAR(1)
> VCHR 37 0 | ???? // VARCHAR(1)

Why ??? for CHAR and VARCHAR, subtype 0 means its CHAR/VARCHAR, and not
BINARY/VARBINARY

Here i was confused by word "untyped" :-)

Isn't char / varchar means data TYPE ?!.. 8-O

...

> BCHR 261 1 2048| [OK] // BLOB ...
> subtype TEXT CHARACTER SET WIN1250
> COMP_TCHR 14 0 | ???? // computed by
> ( CHAR(1) )
> COMP_VCHR 37 0 | ???? // computed by
> ( VARCHAR(1) )

Again, why the ??? (though it could theoretically be losing the subtype
information, just like the earlier example).

Again - confused by word "untyped" :-)

IMO, this sub-section of doc must be refactored (currently it leaves room for different interpretations - at least for non-native English speakers).

> PS.
> The column RDB$FIELDS. RDB$FIELD_SUB_TYPE <https://
> www.firebirdsql.org/file/documentation/html/en/refdocs/fblangref50/
> firebird-50-language-reference.html#fblangref-appx04-fields> is
> described in the doc as:
> =============
> Specifies the subtype for the BLOB data type:
> 0 - untyped (binary)
> 1 - text
> Specifies for the CHAR data type:
> 0 - *untyped* data
> 1 - fixed *binary* data
> =============
> What means " untyped" in the doc for Character type ?

Untyped means it's just a plain CHAR/VARCHAR and doesn't have a more
specific type like BINARY/VARBINARY. However, I'll see if I can rephrase
or clarify it.

Unfortunately, i still can not understand:

"and doesn't have a more specific type like BINARY... " -- do you mean character set ?

The fact it says "CHAR data type" instead of "character data type" or
"CHAR/VARCHAR data type" is an error on my part. I guess when I started
writing it, I wanted to list CHAR and VARCHAR separately, and then
changed my mind. The word binary means it's binary data, not
specifically the BINARY datatype (typography matters here). That "fixed"
probably needs to go as well.

Yes! "fixed" definitely interferes with proper understanding here :-/

PS.

This is script to check rdb$fields content for integer / numeric et al types:

=============

create view v_fields_info as
select
rf.rdb$field_name as rf_fld_name
,f.rdb$field_type as f_field_type
,f.rdb$field_sub_type as f_fld_sub_type

,f.rdb$field_precision as f_fld_prec
,f.rdb$field_scale as f_fld_scale
--,f.rdb$segment_length as f_segm_len

from rdb$relation_fields rf
join rdb$fields f on rf.rdb$field_source = f.rdb$field_name
where rf.rdb$relation_name = coalesce( rdb$get_context('USER_SESSION','DEBUG_REL_NAME'), upper('TEST'))
order by rf.rdb$field_position
;

recreate table test (

id016 smallint
,id032 int
,id064 bigint
,id128 int128

,flt float
,dbl double precision

,num04 numeric(4)
,num09 numeric(9)
,num18 numeric(18)
,num38 numeric(38)
,dec04 decimal(4)
,dec09 decimal(9)
,dec18 decimal(18)
,dec38 decimal(38)

,df16 decfloat(16)
,df34 decfloat(34)

,comp_id016 computed by (id016+0 )
,comp_id032 computed by (id032+0 )
,comp_id064 computed by (id064+0 )
,comp_id128 computed by (id128+0 )

,comp_flt computed by (flt+0 )
,comp_dbl computed by (dbl+0 )

,comp_num04 computed by (num04+0 )
,comp_num09 computed by (num09+0 )
,comp_num18 computed by (num18+0 )
,comp_num38 computed by (num38+0 )

,comp_dec04 computed by (dec04+0 )
,comp_dec09 computed by (dec09+0 )
,comp_dec18 computed by (dec18+0 )
,comp_dec38 computed by (dec38+0 )

,comp_df16 computed by (df16 +0 )
,comp_df34 computed by (df34 +0 )

/*

,comp_tbin computed by ( tbin )
,comp_vbin computed by ( vbin )
,comp_bbin computed by ( bbin )

,comp_tchr computed by ( tchr )
,comp_vchr computed by ( vchr )
,comp_bchr computed by ( bchr )

*/

);

show table test;
commit;
set width RF_FLD_NAME 12;
select * from v_fields_info;

quit;

=============

And this is output on FB 5.x (and same on FB 6.x):

=============

...

RF_FLD_NAME F_FIELD_TYPE F_FLD_SUB_TYPE F_FLD_PREC F_FLD_SCALE
============ ============ ============== ========== ===========
ID016 7 0 0 0
ID032 8 0 0 0
ID064 16 0 0 0
ID128 26 0 0 0
FLT 10 <null> <null> 0
DBL 27 <null> <null> 0
NUM04 7 1 4 0
NUM09 8 1 9 0
NUM18 16 1 18 0
NUM38 26 1 38 0
DEC04 8 2 4 0
DEC09 8 2 9 0
DEC18 16 2 18 0
DEC38 26 2 38 0
DF16 24 <null> 16 0
DF34 25 <null> 34 0
COMP_ID016 16 0 18 0
COMP_ID032 16 0 18 0
COMP_ID064 16 0 18 0
COMP_ID128 26 0 38 0
COMP_FLT 27 <null> <null> 0
COMP_DBL 27 <null> <null> 0
COMP_NUM04 16 1 18 0
COMP_NUM09 16 1 18 0
COMP_NUM18 16 1 18 0
COMP_NUM38 26 1 38 0
COMP_DEC04 16 2 18 0
COMP_DEC09 16 2 18 0
COMP_DEC18 16 2 18 0
COMP_DEC38 26 2 38 0
COMP_DF16 25 <null> 0 0
COMP_DF34 25 <null> 0 0

=============

Dimitry Sibiryakov

unread,

Jul 12, 2026, 7:27:37 AMJul 12

to firebir...@googlegroups.com

Pavel Zotov wrote 12.07.2026 13:11:
> Here i was confused by word "untyped" :-)
> Isn't char / varchar means data TYPE ?!.. 8-O

Word "unsubtyped" just doesn't exists. Perhaps, "generic" would fit?..

--
WBR, SD.

Pavel Zotov

unread,

Jul 12, 2026, 7:39:22 AMJul 12

to firebird-devel

> Here i was confused by word "untyped" :-)
> Isn't char / varchar means data TYPE ?!.. 8-O

Word "unsubtyped" just doesn't exists. Perhaps, "generic" would fit?..

An example which isllustrates two opposite cases ("typed" vs "untyped") will be greatly appreciated.

Mark Rotteveel

unread,

Jul 12, 2026, 7:48:08 AMJul 12

to firebir...@googlegroups.com

The word used is untyped, not unsubtyped.

Mark
--
Mark Rotteveel

Dimitry Sibiryakov

unread,

Jul 12, 2026, 7:51:59 AMJul 12

to firebir...@googlegroups.com

'Mark Rotteveel' via firebird-devel wrote 12.07.2026 13:48:
>>
>> Word "unsubtyped" just doesn't exists. Perhaps, "generic" would fit?..
>
>
> The word used is untyped, not unsubtyped.

Yes, that's the point of my answer: word "untyped" was used in meaning
"unsubtyped". I hope Pavel read it this way.

--
WBR, SD.

Mark Rotteveel

unread,

Jul 12, 2026, 8:07:15 AMJul 12

to firebir...@googlegroups.com

On 12-07-2026 13:11, Pavel Zotov wrote:
> On Sunday, July 12, 2026 at 11:11:53 AM UTC+3 Mark Rotteveel wrote:

> Why the ??? a VARBINARY is a VARCHAR with subtype 1, just like
> BINARY is
> a CHAR with subtype 1.
>

> I was confuced by word "fixed" (from doc: "1 - /fixed/

> binary data") because in my mind this meant fixed length :-)

That is simply as that documentation has basically been copied from the
InterBase 6 documentation, for a feature that actually never existed
(though it seems it would have been close to the current usage).

> > BBIN 261 0 512| [OK] // BLOB
> > subtype BINARY ==> ~ "for the BLOB ... untyped (binary)"
> > COMP_TBIN 14 0 | ???? //
> computed
> > by: ( BINARY(1) )
> > COMP_VBIN 37 0 | ???? //
> computed
> > by: ( VARBINARY(1) )
>
>
> Sounds like a bug in the type derivation, losing the subtype. This is
> not unheard of, I think it also happens (or happened, I haven't checked
> now) with computed columns involving NUMERIC and DECIMAL.
>
>
> i could not find any note in the doc what values must be assigned to
> rdb$field_type & rdb$field_sub_type for COMPUTED column if it is based
> on integer (numeric) column.

That's because that is not something subject to documentation, though
integer types with sub-type 0 and a non-zero scale should be considered
as NUMERIC (or DECIMAL).

> Outcome of similar script (slightly modified from original post, see it
> below) show that:
> * when base column type belongs to smallint, int or bigint then computed
> column will have field_type = 16 and sub_type = 0 (i.e. this is BIGINT);
> * when base type is int128 then computed column will have same type
> (field_type = 26 and sub_type = 0);
> * for base type beloging to numeric and decimal types with up to 18
> digits - computed column will be either numeric(18) or decimal(18);
> otherwise - numeric(38) or decimal(38). NOTE: sub_type differs for such
> computed columns thus we able to distinguish them;

That was historically not the case (e.g. see
https://github.com/FirebirdSQL/firebird/issues/2785).

I believe there are some cases where exact numeric literals with a
decimal do have a scale, but have no subtype in the XSQLDA descriptors.

[..]

> Here i was confused by word "untyped" :-)
> Isn't char / varchar means data TYPE ?!.. 8-O

Yes, and that is defined by the RDB$FIELD_TYPE, and with subtype 0,
there is not a more specific subtype than what's defined by that type.

> ...
> > BCHR 261 1 2048| [OK] //
> BLOB ...
> > subtype TEXT CHARACTER SET WIN1250
> > COMP_TCHR 14 0 | ???? //
> computed by
> > ( CHAR(1) )
> > COMP_VCHR 37 0 | ???? //
> computed by
> > ( VARCHAR(1) )
>
>
> Again, why the ??? (though it could theoretically be losing the subtype
> information, just like the earlier example).
>
>
> Again - confused by word "untyped" :-)
> IMO, this sub-section of doc must be refactored (currently it leaves
> room for different interpretations - at least for non-native English
> speakers).

Untyped means "not typed", and here it means that there is not a more
specific (sub)type, which means the primary type, RDB$FIELD_TYPE, *is*
the type.

> > PS.
> > The column RDB$FIELDS. RDB$FIELD_SUB_TYPE <https://
> > www.firebirdsql.org/file/documentation/html/en/refdocs/

> fblangref50/ <http://www.firebirdsql.org/file/documentation/html/en/

> refdocs/fblangref50/>
> > firebird-50-language-reference.html#fblangref-appx04-fields> is
> > described in the doc as:
> > =============
> > Specifies the subtype for the BLOB data type:
> > 0 - untyped (binary)
> > 1 - text
> > Specifies for the CHAR data type:
> > 0 - *untyped* data
> > 1 - fixed *binary* data
> > =============
> > What means " untyped" in the doc for Character type ?
>
> Untyped means it's just a plain CHAR/VARCHAR and doesn't have a more
> specific type like BINARY/VARBINARY. However, I'll see if I can
> rephrase
> or clarify it.
>
>
> Unfortunately, i still can not understand:
> "and doesn't have a more specific type like BINARY... " -- do you mean
> character set ?

No, I mean when RDB$FIELD_TYPE is 14, it is a CHAR, unless the
RDB$FIELD_SUB_TYPE is 1, then it is a more specific (sub)type, which is
BINARY. Same for RDB$FIELD_TYPE is 37, but then VARCHAR vs VARBINARY.

Or phrased differently, if the subtype is 0 (or NULL), the subtype is
"untyped" (read, not typed), and that means it's the primary datatype
(CHAR or VARCHAR), or phrased yet differently again, the datatype is not
further differentiated (or, made more specific) from its primary type.

This is also how it works for integer/exact numeric types, and for blobs
(though for blobs, you can explicitly specify the 0/BINARY subtype if
you want).

Mark
--
Mark Rotteveel

Mark Rotteveel

unread,

Jul 12, 2026, 8:13:34 AMJul 12

to firebir...@googlegroups.com

On 12-07-2026 13:11, Pavel Zotov wrote:

> COMP_DF16 25 <null> 0 0
> COMP_DF34 25 <null> 0 0

FYI, this would seem to be a bug with computed columns derived from a
DECFLOAT: it doesn't set the precision.

Mark
--
Mark Rotteveel

Pavel Zotov

unread,

Jul 12, 2026, 9:50:48 AMJul 12

to firebird-devel

Yes, i've already noted this a few days ago :-)

But this is better to discuss separately:

https://groups.google.com/g/firebird-devel/c/DQ8fCFerQXk/m/eMnK1g6XAwAJ

Adriano dos Santos Fernandes

unread,

Jul 13, 2026, 9:28:14 PMJul 13

to firebir...@googlegroups.com

That topic was about CTAS and while fixing it, I noticed others parts
would have the same problem. I didn't touched that parts.

Adriano

Reply all

Reply to author

Forward