* Guilhem Bichot <guilhem@stripped> [08/06/26 16:36]:
> I didn't really follow your discussion with Monty yesterday about
> those functions and their influence on sql/, but a fact maybe
> worth nothing is that in 6.0-maria (very soon to be merged into 6.0),
> we have done a change: in 6.0 right now, the order is
> to lock: external_lock and then thr_lock
> to unlock: thr_unlock and then external_lock
> and the change is that to unlock, the new order is:
> external_lock and then thr_unlock.
> Thus, restore_status and update_status calls have moved from
> mysys/thr_lock.c to storage/myisam/mi_locking.c
> But get_status and copy_status are still in thr_lock.c
In future, when working with advanced engines, we may want to
be able to use a table without calling thr_lock on it.
One reason is that we may decide to use a table in the middle of a
statement, and thr_lock doesn't support getting locks in arbitrary
order. Another is that we may simply want to open many
cursors to a given table inside a single statement.
thr_lock is only needed for simplistic engines. Since you're going
to have an own lock manager and deadlock resolution, I don't see
any need to use it in Maria.
It would be pity if Maria will put itself out of consideration,
when it comes to support of dynamic sql in stored functions,
pluggable stored procedures, advanced partition pruning, recursive
foreign keys, and all only because it relies on get_status and
copy_status being called for each used table instance.
I anticipate that Monty will come with an argument that it's
possible to make thr_lock work with all the advanced features we
have in mind. That's true, but it's exactly what Maria in my view
should be about, while thr_lock should belong to our happy
and simple past.