Is the BLR code blr_default2 really needed, or is it just a minor optimization?

[Alexey Mochalov]

Along with schemas, a new BLR code blr_default2 was introduced. In case the table schema (from which the default value is taken) does not match dsqlScratch->ddlSchema, the BLR code stores not only the default value itself but also the schema. Since dsqlScratch->ddlSchema inside a package is set to the package’s schema, the generated default values ignore the original schema and do not use it when generating BLR.

I would appreciate help and advice: is this actually necessary (and in what cases), or is it just a small optimization to reduce the length of the default value’s BLR code?

The problem appeared while merging the rowtype feature and schemas in the part related to package types and their default values. If the schema is not explicitly included in the BLR code of the default value, later an error occurs when resolving fields mentioned in the default expression against the fields declared in the package type, because without the schema the package type cannot be found.

My suggestion is to remove blr_default2 and use the old blr_default, while always writing the schema name in the default value.
Are there really complex cases where the explicit schema name could cause issues inside a default value?

Thanks,
Alexey Mochalov

[Adriano dos Santos Fernandes]

On 9/19/25 06:16, Alexey Mochalov wrote:
> Along with schemas, a new BLR code *blr_default2* was introduced. In

> case the table schema (from which the default value is taken) does not
> match dsqlScratch->ddlSchema, the BLR code stores not only the default
> value itself but also the schema. Since dsqlScratch->ddlSchema inside a
> package is set to the package’s schema, the generated default values
> ignore the original schema and do not use it when generating BLR.
>

Looks like you don't understand blr_default[2].

It never used the default value there, but the table + column name.


Adriano

[Alexey Mochalov]

That’s correct for blr_default, while blr_default2 also includes the schema.
In my implementation blr_default likewise refers to the package type name and its fields, but since packages can now also reside in schemas, I need to distinguish package type names within packages by schema.

And I would be grateful if you could answer the questions I asked.

Thanks,

Alexey Mochalov

пятница, 19 сентября 2025 г. в 13:34:30 UTC+3, Adriano dos Santos Fernandes:

[Adriano dos Santos Fernandes]

On 9/19/25 08:14, Alexey Mochalov wrote:
> That’s correct for *blr_default*, while *blr_default2* also includes the
> schema.
> In my implementation *blr_default* likewise refers to the package type

> name and its fields, but since packages can now also reside in schemas,
> I need to distinguish package type names within packages by schema.
>
> And I would be grateful if you could answer the questions I asked.
>

You said blr_default[2] encodes "the default value itself". That's plain
wrong and I can't answer it different.

I still do not understand what the problem is and how you want to solve
it removing blr_default2.


Adriano

[Alexey Mochalov]

Sorry for the misunderstanding. When I said “the default value itself,” I meant a reference to a table field by its names—exactly as you described.

The package type is implemented so that each of its fields can have a default value. To initialize a variable of the package type with defaults, I use a row-value constructor with blr_default for each field. Since the type is compiled inside the package with dsqlScratch->ddlSchema set to the package’s schema, there is no schema-name mismatch during BLR generation, and the schema is not included (i.e., blr_default2 is not produced).

Later, when the package type is used, default values are resolved by looking up the table name that contains the generated package-type name, and then searching in RDB$RELATION_FIELDS. Because the schema name is missing there (compilation used blr_default due to matching schemas inside the package), the match fails and the field is not found. Always including the schema name in blr_default would avoid this.

In theory, I could manually clear dsqlScratch->ddlSchema before generating the package type’s default initializer and restore it afterwards, but that feels hacky.

It seemed to me that this optimization (if I understood correctly that it’s merely an optimization and not a fix for some issue—you haven’t answered that yet) could be removed, saving one BLR code in the process.

I’m not insisting on removing blr_default2; I’m trying to gather more information and hear the schema developer’s opinion.

Thanks,
Alexey Mochalov

пятница, 19 сентября 2025 г. в 14:18:43 UTC+3, Adriano dos Santos Fernandes:

[Dmitry Yemanov]

19.09.2025 15:02, Alexey Mochalov wrote:

> Always including the schema name in blr_default would avoid this.

We cannot (due to backward compatibility) change blr_default to include
schema name there. This is exactly why blr_default2 was added.


Dmitry

[Alexey Mochalov]

Right, I missed that. Thank you. I withdraw my proposal about blr_default2.

Thanks,

Alexey Mochalov

пятница, 19 сентября 2025 г. в 15:28:42 UTC+3, Dmitry Yemanov: