Subject RE: Firebird beeing inconsistent in regards to accepting UDFs?

---In, <lester@...> wrote:

Dimitry Sibiryakov wrote:
>> Why it is a bug?
> Because it allows an invalid object to exist in database after commit. Such behavior is
> a bug, bringing database into not usable state.

I understand what you are saying, and it would be useful if we had a warning.
However just as there is no requirement for the UDF to exist before creating the
connection, there is no way of ensuring it has not later been deleted or
corrupted? (...)  and the database is
not in an unusable state, just some queries fail to work which is often why I
find the problem :) The data is perfectly safe?

Exactly, if we have not full control over the UDF file then why to fixing something that it can still be broken in other way?

Take a look at my real life example: I have 1000 clients. I need UDF functionality in 1 client but I want to run update script on all clients. If you do not allow me to run this update script because UDF file is not present then I am in a big trouble because I would have to copy UDF file to 999 clients and they do not need it.

IMHO what should be fixed is the exception that will not allow me to create a stored procedure containing UDF without a file.

Besides, I can easly overcome this exception by embeeding EXECUTE BLOCK in stored procedure that will call UDF. You would have to also block this possibility otherwise it would be still inconsistent behaviour.