Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Predicate (blob_field LIKE ?) describes the parameter as VARCHAR(30) rather than as BLOB [CORE3353] #3719

Closed
firebird-automations opened this issue Feb 17, 2011 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Joe Slater (joeslater)

Relate to CORE3408
Is related to JDBC132

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.

Commits: 632287c 8ac7178 f007504

====== 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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

reporter: Dmitry Yemanov [ dimitr ] => Joe Slater [ joeslater ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5.1 [ 10333 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 2.1.5 [ 10420 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Ann Harrison (awharrison)

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.

Cheers,

Ann

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Ann,

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE3408 [ CORE3408 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @mrotteveel

Link: This issue is related to JDBC132 [ JDBC132 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: Done successfully

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment