Shared metacache: refreshing TYPE OF COLUMN parameters after ALTER TABLE

[Alexey Mochalov]

Hi,

Could you clarify the expected behavior of TYPE OF COLUMN parameters with the new shared metadata cache when AUTODDL is disabled (i.e. in same transaction)?

In the following example, I create a table and a function, reference the function, and then change the column type from INTEGER to CHAR(11):

```sql
SET AUTODDL OFF;

CREATE TABLE ttt (field1 INTEGER);

SET TERM !;

CREATE FUNCTION fff (arg1 TYPE OF COLUMN ttt.field1)
    RETURNS TYPE OF COLUMN ttt.field1
AS
BEGIN
    RETURN :arg1;
END!

SET TERM ;!

-- Fails as expected
SELECT fff('text') FROM rdb$database;

ALTER TABLE ttt ALTER field1 TYPE CHAR(11);

-- Statement succeeds
INSERT INTO ttt VALUES ('text');

-- Still fails
SELECT fff('text') FROM rdb$database;

COMMIT;

-- Still fails after COMMIT
SELECT fff('text') FROM rdb$database;
```

The table reflects the new column type, but the function appears to retain its original INTEGER parameter and return descriptors.

Should altering the source column invalidate and reload the function metadata within the same transaction, including when the function itself has not yet been committed? If that is not supported, should the subsequent COMMIT make the new type visible to later calls in the same attachment?

Is this an expected limitation, or a missing implementation?

Thanks,
Alexey Mochalov.

[Alex Peshkoff]

On 9/25/26 14:53, Alexey Mochalov wrote:

Should altering the source column invalidate and reload the function metadata within the same transaction, including when the function itself has not yet been committed? If that is not supported, should the subsequent COMMIT make the new type visible to later calls in the same attachment?

I'm currently working on it (branch depend_update). There are a lot of cases with more or less such problem, I want to have generic solution. And your sample is very useful.