MySQL:当存储过程参数名称与表列名称相同时[继续]

发布于 2024-07-19 05:40:26 字数 727 浏览 13 评论 0 原文

假设有一个存储过程 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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

零度℉ 2024-07-26 05:40:26

我不明白为什么你需要首先使用反引号来转义。
在语句 UPDATE x SET a = b 中,a 必须始终引用 x 列。 b 但是可以是变量或列。 鉴于本地范围和变量解析在存储过程中的工作方式< /a>, b 将始终引用局部变量,即使 x 中存在同名列。

因此,我无法重现您的问题。 我尝试了这种方式:

mysql> SELECT * FROM comments;
+----+-----------+---------+
| id | parent_id | content |
+----+-----------+---------+
|  1 |         0 | bar     | 
|  2 |         0 | baz     | 
+----+-----------+---------+
2 rows in set (0.00 sec)
mysql> delimiter //
mysql> CREATE PROCEDURE foo(IN content TEXT)
    -> BEGIN
    ->   UPDATE comments SET content = content;
    -> END //
Query OK, 0 rows affected (0.00 sec)
mysql> delimiter ;
mysql> CALL foo('changed!');
Query OK, 2 rows affected (0.00 sec)
mysql> SELECT * FROM comments;
+----+-----------+----------+
| id | parent_id | content  |
+----+-----------+----------+
|  1 |         0 | changed! | 
|  2 |         0 | changed! | 
+----+-----------+----------+
2 rows in set (0.00 sec)

如您所见,注释表的列 content 得到更新,即使 content 也是存储过程的参数名称 foo.

您确定 UPDATE 客户 SET Name = Name; 给你一个错误?
通过上述解释,似乎合乎逻辑的是,

UPDATE customers SET Name = `Name`;
UPDATE customers SET `Name` = Name;
UPDATE customers 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:

mysql> SELECT * FROM comments;
+----+-----------+---------+
| id | parent_id | content |
+----+-----------+---------+
|  1 |         0 | bar     | 
|  2 |         0 | baz     | 
+----+-----------+---------+
2 rows in set (0.00 sec)
mysql> delimiter //
mysql> CREATE PROCEDURE foo(IN content TEXT)
    -> BEGIN
    ->   UPDATE comments SET content = content;
    -> END //
Query OK, 0 rows affected (0.00 sec)
mysql> delimiter ;
mysql> CALL foo('changed!');
Query OK, 2 rows affected (0.00 sec)
mysql> SELECT * FROM comments;
+----+-----------+----------+
| id | parent_id | content  |
+----+-----------+----------+
|  1 |         0 | changed! | 
|  2 |         0 | changed! | 
+----+-----------+----------+
2 rows in set (0.00 sec)

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

UPDATE customers SET Name = `Name`;
UPDATE customers SET `Name` = Name;
UPDATE customers SET `Name` = `Name`;

all have the same effect.

Edit: The situation would be different for SELECT statements, of course.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文