← Back to team overview

maria-developers team mailing list archive

Re: MDEV-26742 Assertion `field->type_handler() == this' failed...


On 10/12/21 8:46 PM, Sergei Golubchik wrote:
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.

This code is not heavily loaded and should not affect performance.
I prefer the generic way.

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.

VP of MariaDB Server Engineering
and security@xxxxxxxxxxx

Follow ups