It's expected that LIKE should behave similarly to basic comparison operators ("equal to" etc) in describing the parameter type if the known parameter is of the string/blob type. However, (blob_field = ?) expectedly describes the parameter as BLOB, but (blob_field LIKE ?) describes it as VARCHAR. The same issue applies to CONTAINING/STARTING/SIMILAR TO predicates.
In the very bad, very old days, blob=blob tested to see if the blob handles were the rather
than comparing the contents of the blob. That model works very badly for containing,
starting, similar, like, etc. I trust that by now the concept of comparing blob handles has
disappeared into history.
The answer is both yes and no. All blob based booleans are evaluated properly, by comparing the contents (including charset/collation trickery for text blobs). However, there's one known issue in this area, see CORE3278.
But there are cases where blob IDs are still compared. I mean sorting and all its derived operations (ORDER BY, GROUP BY, DISTINCT). With a fixed length sorting operations, it looks impossible to process the entire blob contents, at least easily. But an attempt to throw error in these cases failed due to backward compatibility issues. See CORE859, CORE3252, CORE3253. Sigh.
Test Details: Note for 2.5.
Parameters in SQLDA have type from src/dsql/sqlda_pub.h, but bit_0 is ON if this parameter is Nullable, i.e.:
#define SQL_BLOB 520 ==> 521 for Nullable (see also: core_4156.fbt)
Note for 3.0.
NB: output in 3.0 will contain values of sqltype with ZERO in bit_0, so it will be: 520 instead of previous 521.