假设有一个存储过程 SetCustomerName,它有一个输入参数 Name,并且我有一个包含 Name 列的表customers。 因此,在我的存储过程中,我想设置客户的姓名。 如果我写
UPDATE customers SET Name = Name;
这是不正确的,我必须写(例如)
UPDATE customers SET `Name` = Name;
所以,有一个关于反引号的链接(http://dev.mysql.com/doc/refman/5.0/en/identifiers.html),但没有足够深入地解释如何使用它们(如何使用它们参数和列名称)。
有一件非常奇怪的事情(至少对我来说):您可以以任何一种方式使用反引号:
UPDATE customers SET Name = `Name`;
//or
UPDATE customers SET `Name` = Name;
//or even
UPDATE customers SET `Name` = `Name`;
而且它们的工作方式完全相同。
你不觉得这很奇怪吗? 这种奇怪的行为是否在某处得到了解释?
Let's say a have a stored procedure SetCustomerName which has an input parameter Name, and I have a table customers with column Name. So inside my stored procedure I want to set customer's name. If I write
UPDATE customers SET Name = Name;
this is incorrect and I have to write (for example)
UPDATE customers SET `Name` = Name;
So, there is a link about backticks (http://dev.mysql.com/doc/refman/5.0/en/identifiers.html) but it's not explained deep enough how to use them (how to use them with parameters and column names).
And there is a very strange thing (at least for me): You can use backticks either way:
UPDATE customers SET Name = `Name`;
//or
UPDATE customers SET `Name` = Name;
//or even
UPDATE customers SET `Name` = `Name`;
and they all work absolutely the same way.
Don't you think this is strange? Is this strange behavior explained somewhere?
发布评论
评论(1)
我不明白为什么你需要首先使用反引号来转义。
在语句 UPDATE x SET a = b 中,a 必须始终引用 x 列。 b 但是可以是变量或列。 鉴于本地范围和变量解析在存储过程中的工作方式< /a>, b 将始终引用局部变量,即使 x 中存在同名列。
因此,我无法重现您的问题。 我尝试了这种方式:
如您所见,注释表的列 content 得到更新,即使 content 也是存储过程的参数名称 foo.
您确定 UPDATE 客户 SET Name = Name; 给你一个错误?
通过上述解释,似乎合乎逻辑的是,
所有这些都具有相同的效果。
编辑:当然,对于 SELECT 语句,情况会有所不同。
I do not understand why you need to escape using backticks in the first place.
In a statement UPDATE x SET a = b, a must always refer to a column of x. b however can either be a variable or a column. Given how local scope and variable resolution works in stored procedures, b will always refer to the local variable, even if a column with the same name in x exists.
Thus, I am unable to reproduce your problem. I tried this way:
As you can see, the comment-table's column content gets updated, even though content is also the name of the parameter of the stored procedure foo.
Are you sure that UPDATE customers SET Name = Name; gives you an error?
With the above explanation, it seems logical that
all have the same effect.
Edit: The situation would be different for SELECT statements, of course.