Regression: "Blob not found" exception after insert, select and delete in procedure

[abzalov]

create database 'c:\test.fdb' user 'sysdba' password 'masterkey';

create table t(c blob sub_type 1);
commit;
 
set term ^;

create or alter procedure p returns (c blob sub_type 1)
as
begin
  insert into t(c) values ('AAA!');
  select c from t into :c;
  delete from t;
  suspend;
end^

commit^

select * from p^;

Output FB 4.0: BLOB not found. Output FB 2.5: AAA!

Expected behavior is returning the blob data copied before it delete.

[aafemt]

This behavior is "as designed" and fixing it would result in significant performance penalty.

On 2.5 the error was raised as well if UPDATE is used instead of DELETE. Now it is at least consistent...

[dyemanov]

Assignment to a BLOB variable copies the blob ID, not the blob contents. If the blob is removed in the meantime, the blob ID cannot be used to access the blob anymore.

[aafemt]

Theoretically whole BLOB could be copied into the temporary tablespace unless it is already there but that's performance penalty I was talked about. Another solution could be reference-counted BLOB IDs.

[abzalov]

I have no doubt what is going on inside - it's obvious.

This could be considered "as design" if we were provided with methods for copying the content of the blob like in Oracle. And now this "design" is not self-sufficient.

You cannot break previously working things without providing working alternatives.

[aafemt]

Do "c = c||'';" and yuo'll get what you want.

[abzalov]

What about blobs greater than 64K?

If there is no such restriction now, when can we expect it? After removing one hack, you will provide the another.

[aafemt]

What about blobs greater than 64K?

Concatenation works with them without problems and no restriction is going to be applied.