Commented by: Claudio Valderrama C. (robocop)

This is really funny case:
SQL> select avg(null) from rdb$relations;
Statement failed, SQLCODE = -902
Dynamic SQL Error
-expression evaluation not supported
SQL> select sum(null) from rdb$relations;
Statement failed, SQLCODE = -902
Dynamic SQL Error
-expression evaluation not supported

You don't need to have a dialect 1 db. You only need to change the connection dialect to be 1:
SQL> set sql dialect 1;
WARNING: Client SQL dialect has been set to 1 when connecting to Database SQL dialect 3 database.
SQL> select sum(null) from rdb$relations;

                SUM

=======================
<null>

SQL> select avg(null) from rdb$relations;

                AVG

=======================
<null>

and it works. Inconsistent for the average user.

Commented by: @dyemanov

While reviewing this ticket, I have one doubt. We describe the NULL literal as CHAR(1). Some arithmetical expressions change the datatype to something more appropriate, e.g. NULL + NULL = NULL as INT. MIN/MAX accept string inputs so MIN(NULL) = NULL as CHAR(1). But what AVG/SUM should return in this case? In usual conditions, they cannot return string data, so returning CHAR(1) looks a bit weird. Should the result be INT? Or maybe DOUBLE PRECISION?