MySQL Bugs: #78867: Having to lock tables by specifying every single alias is completely ridiculous

Bug #78867	Having to lock tables by specifying every single alias is completely ridiculous
Submitted:	17 Oct 2015 20:58	Modified:	20 Oct 2015 14:49
Reporter:	teo teo	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Logging	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
http://dev.mysql.com/doc/refman/5.6/en/lock-tables.html

> If your statements refer to a table by means of an alias, 
> you must lock the table using that same alias. It does not 
> work to lock the table without specifying the alias:

That's f***ing ridiculous. If you are using a table with several alias, you have to lock it for every single alias with which you may refer it in queries? There's no reason for requiring that.

You should be able to just do:

LOCK TABLES sometable WRITE

SELECT * FROM sometable AS t

why the hell should aliases matter?!?

How to repeat:
LOCK TABLES sometable WRITE

SELECT * FROM sometable AS t

Suggested fix:
Aliases should be totally irrelevant for locking

Sorry, but this is not a bug.

That is how behavior was designed and coded some 12 years ago.

So, it works as designed. Hence, not a but. But, if you wish, I can verify it as a feature request. In that case, it is unknown when will this behavior be changed.

> That is how behavior was designed and coded some 12 years ago.

That alone doesn't mean it's not a bug. Unless you make a distinction between a bug (something that doesn't work as designed) and a design flaw (something that was designed the wrong way), but that's a distinction that in the end boils down to the magnitude of an oversight, and hence is basically arbitrary.

So the question is: can you give a GOOD REASON why it was designed this way? Can you name ONE advantage over the obvious alternative which is not having to name aliases, given that what is locked are tables?
Because if you can, then *maybe* this is not a design flaw, otherwise, whether you prefer to call it a feature request or a bug, it's something that is wrong and should be fixed.

By the way, the fact that it has been this way for 12 years means nothing. Bugs and wrong designs often live on for decades in software, and MySQL is no exception (see the ridiculous 25-word-long message that introduces a syntax error before giving a single bit of information, and still fails to be unambiguous at word 25)

Hi.

Yes, there is a very good reason why is a design like that. If aliases are not locked, you can generate a deadlock.

There was and may be still is an example about it, somewhere in the manual.

Also, design flaws are not bugs. In the best case they can be only feature request. But, deadlocks are a very good reason for this design.

Of course, avoiding a deadlock is a very good reason for a design decision. That is, if the possibility of a deadlock is consustantial to the design decision at hand, rather than caused by a bug somewhere else in the implementation.

I'd like to see the deadlock example, and see how that would be an inevitable consequence of locking tables without specifying aliases rather than caused by a bug somewhere else.

Note that when I talk about locking table without specifying aliases what I mean is that by locking a table, all queries that access that table would be affected by the lock regardless of the aliases they use to access it.