为什么 Oracle 不提出“ORA-00918:列定义不明确”?对于这个查询?
我刚刚在 Oracle 中遇到了一个奇怪的行为,我希望会引发 ORA-00918,但事实并非如此。以这个查询为例。
SELECT *
FROM USER_TABLES TAB
JOIN USER_TRIGGERS TRG ON TRG.TABLE_NAME = TAB.TABLE_NAME
WHERE STATUS = 'DISABLED'
该查询理论上是在查找禁用触发器的表的详细信息,但请注意,这不是我要解决的问题。这个问题并不是这个查询、数据字典、视图或表所独有的;据我所知,它适用于任何一组表或视图(我尝试过的两三个)。
无论如何,尝试运行此查询,您会得到 ORA-00918,因为 USER_TABLES
和 USER_TRIGGERS
都有一个名为 STATUS
的列,因此要获取查询运行WHERE
子句需要更改为TRG.STATUS
。好的,很酷,但是尝试加入另一张桌子。
SELECT *
FROM USER_TABLES TAB
JOIN USER_TRIGGERS TRG ON TRG.TABLE_NAME = TAB.TABLE_NAME
JOIN USER_CONSTRAINTS CON ON CON.TABLE_NAME = TAB.TABLE_NAME
WHERE STATUS = 'DISABLED'
这个查询,无需限定您所指的 STATUS 列,就能神奇地工作!不要介意语义或查询返回什么,没有错误。 USER_CONSTRAINTS
甚至还有一个名为 STATUS
的列,那么当有两列可供选择但可以接受更多歧义时,它为什么不知道要做什么呢?
顺便说一句,这一切都在 10.2.0.3.0 上,如果查询中有两个以上的表,本质上 ORA-00918 就会停止引发。如果这是一个 Oracle 错误,有谁知道它何时被修复,那么如果我们的数据库升级,哪个 Oracle 版本可能会导致牛仔查询崩溃?
更新
感谢 BQ 演示该错误已在 11.2.0.1.0 中修复。任何可以证明它已在早期版本中修复的人都将得到赏金!
I've just come across a strange behaviour in Oracle where I would expect ORA-00918 to be raised, but isn't. Take this query, for example.
SELECT *
FROM USER_TABLES TAB
JOIN USER_TRIGGERS TRG ON TRG.TABLE_NAME = TAB.TABLE_NAME
WHERE STATUS = 'DISABLED'
This query is notionally looking for the details of tables with disabled triggers, but please note that this is not the problem I'm trying to solve. The problem is not unique to this query, the data dictionary, views or tables; as far as I can tell it applies to any set of tables or views (from the two or three I've tried).
Anyway, try to run this query and you get ORA-00918 because both USER_TABLES
and USER_TRIGGERS
have a column called STATUS
so to get the query to run the WHERE
clause needs to be changed to TRG.STATUS
. Ok, cool, but try instead joining another table.
SELECT *
FROM USER_TABLES TAB
JOIN USER_TRIGGERS TRG ON TRG.TABLE_NAME = TAB.TABLE_NAME
JOIN USER_CONSTRAINTS CON ON CON.TABLE_NAME = TAB.TABLE_NAME
WHERE STATUS = 'DISABLED'
This query, without qualifying which STATUS column you mean, magically works! Never mind the semantics or what the query returns, there is no error. USER_CONSTRAINTS
even has a column called STATUS
too, so how come it doesn't know what to do when there are two columns to choose from but it's okay with even more ambiguity?
This is all on 10.2.0.3.0 by the way, and in essence ORA-00918 stops being raised if you have more than two tables in your query. If this is an Oracle bug, does anyone know when it was fixed and so which Oracle version is likely to cause cowboy queries to blow up if our database is upgraded?
Update
Thanks to BQ for demonstrating the bug is fixed in 11.2.0.1.0. Bounty for anyone that can show it fixed in an earlier version!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
搜索 Oracle 支持并发现以下内容:
Bug 5368296 - ANSI join SQL may not reports ORA-918 for ambigeous columns [ID 5368296.8]
确认受影响的版本:
此问题已
不发布更多内容,因为您需要 Oracle 支持帐户才能查看详细信息,但认为受影响的 Oracle Bug 编号/版本可以分享以指出您在 Oracle 支持上找到正确的方向。
Searched Oracle Support and found this:
Bug 5368296 - ANSI join SQL may not report ORA-918 for ambiguous column [ID 5368296.8]
Versions confirmed as being affected:
This issue is fixed in
Not posting more than that since you need an Oracle Support account to view the details, but thought the Oracle Bug number/versions affected would be okay to share to point you in the right direction on Oracle Support.
不能说它是什么时候修复的,但这是我的结果:
Can't say when it was fixed, but here's my results:
您正在使用 ANSI SQL。我猜测它将 where 子句中的 STATUS 与驱动表相关联。
当您使用“oracle”语法时,您将看到预期的行为。
You are using ANSI SQL. I'm guessing that it associates the STATUS in the where clause with the driving table.
When you use "oracle" syntax you'll see the expected behaviour.
有关于此的更多已确认错误: http://oracledoug.com /serendipity/index.php?/archives/1555-Bug-Hunting.html
最新更新是在 11.2.0.2 中修复
More confirmed bug about this here: http://oracledoug.com/serendipity/index.php?/archives/1555-Bug-Hunting.html
Latest update is that it's fixed in 11.2.0.2
好吧,如果我在 11.2.0.2.0 上尝试这个,我也会遇到同样的问题。不管功能如何,如果添加一些左连接和右连接,这个错误似乎根本无法修复!
Well, if I try this on 11.2.0.2.0, I get the same issue. Regardless of the functionality, if you add in some left and right joins, this bug does not seem to be fixed at all!