Hi, Alexander! On Oct 12, Alexander Barkov wrote:
diff --git a/sql/field.cc b/sql/field.cc index 46a3a1deea3..fc3456e2ccb 100644 --- a/sql/field.cc +++ b/sql/field.cc @@ -7368,7 +7368,9 @@ bool Field_longstr::cmp_to_string_with_same_collation(const Item_bool_func *cond, const Item *item) const { + Type_handler_hybrid_field_type cmp(type_handler_for_comparison());
Can this be anything else but type_handler_long_blob ? if not, then I'd suggest
Type_handler_hybrid_field_type cmp(type_handler_long_blob); DBUG_ASSERT(type_handler_for_comparison() == &type_handler_long_blob);
Generally we don't know. It's now for every single plugin to decide. One can make a plugin using Field_longstr as a base for its Field, but with a different comparison type handler.
I wrote it in a generic way which should work for all cases.
Yes, I know. But practically we won't have such plugins for quite a while, so I'd rather prefer a shorter execution path and a faster code. And an assert that will remind us to implement your gneralized approach when the assumption will be broken.
One more question. What type do we have where you need to aggregate here and simple
item->type_handler_for_comparison() != &type_handler_long_blob
won't do?
We don't know. It's for a plugin to decide if its data type is stronger of weaker than CHAR/VARCHAR/TEXT. For INET6 and UUID we decided they are stronger. But eventually we may want to add some weaker data type.
Same here. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org