Another sample:

DDL:
####
create or alter view v as select 1 id from rdb$database;
commit;
set term ^; create or alter procedure p as begin end^
set term ;^
commit;
--------
recreate table doc(doc_id int);
-----
set term ^;
create or alter procedure p(a_doc_id integer)
returns (o_value numeric(15,4)) as
begin
  o_value = 1;
  suspend;
end;
^set term ;^
commit;
--------
create or alter view v as
select
  d.doc_id,
  cast(sp.o_value as double precision) n
  --sp.o_value
from doc d
  left join p(1) sp on 1=1;
commit;
quit;


Then let's try to drop both view and procedure using common script:

set autoddl off;
set bail on;
commit;

create or alter view v as select
  0 as doc_id
, 0 as o_value
from rdb$database;
----
set term ^;
create or alter procedure p(a_doc_id integer)
returns (o_value numeric(15,4))
AS
 begin
  suspend;
end;
^set term ;^
----
set term ^;
execute block as begin
  execute statement 'drop view v;';
  when any do begin end
end^
set term ;^
----
set term ^;
execute block as begin
  execute statement 'drop procedure p;';
  when any do begin end
end^
set term ;^


The message about dependencies appear instead of successful deletion:
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-cannot delete
-PROCEDURE P
-there are 1 dependencies
After line 31 in file t0_run.sql

If we change the view:

create or alter view v as
select
  d.doc_id,
  sp.o_value n -- *DELETE* cast from this field
from doc d
  left join p(1) sp on 1=1;
commit;

-- no errors occured.
If we create view without join table and SP - no errors also.

Today isql produced coredump with some of scripts that performed "bulk update" of metadata.
Connect was made via -ch utf8.
Two variant of backtrace in attach (for /opt/firebird/bin/isql and .../bin/.debug/isql.debug).

HTH

A new regression is found because of this change. Simple test case:

create view v as
select t4.rdb$relation_name
from rdb$relations t1, rdb$relations t2, rdb$relations t3, rdb$relations t4;

-- reconnect

alter view v as
select 0 as rdb$relation_name from rdb$database;

-- no commit here

drop view v;

-- the engine crashes

When MET_scan_relation() is called during DROP, we have the new field list and view BLR out of sync with the RDB$RUNTIME which is modified at the commit time only and thus preserving the original structure.

New fix solves the problem. Thank you.

Additional fix is committed. Please check and confirm if it is ok.

The bugfix makes it impossible to drop certain tables with computed fields. Test case was sent privately to Vlad Horsun.

I believe this bugfix also is the cause of CORE-3579 regression.

The reason of the problem is that Vlad's code calls MET_scan_relation when relation fields are already deleted.
This fails and DROP TABLE statement fails with it.

Another test case (requires FB 2.5 or higher)

1.
firebird\bin>isql
create database 'core-3557.fdb';
create table t (id int);
exit;

2.
firebird\bin>isql CORE-3557.FDB
set term ^;
execute block as
begin
  execute statement 'drop table t';
  in autonomous transaction do
    execute statement ('insert into t values (1)');
end
^

Statement failed, SQLSTATE = 08006
connection lost to database

To reproduce:

1. Prepare database and disconnect

firebird\bin>isql
create database 'core-3557.fdb';
create table t (id int);
exit;

2. First session: drop table and do not commit transaction
firebird\bin>isql core-3557.fdb
set autoddl off;
drop table t;

3. Second session: run query against dropping table
firebird\bin>isql core-3557.fdb
set autoddl off;
commit;
insert into t values (1);

Statement failed, SQLSTATE = 08006
connection lost to database

Firebird crashed