为什么Oracle 10g不会抱怨列不明确？

我使用Oracle 10g（XE 10.2.0.1.0），发现我不明白一个问题：为什么Oracle 10g不会抱怨列不明确？

select * 
from employees manager 
    join employees worker on MANAGER.EMPLOYEE_ID = WORKER.MANAGER_ID 
    join departments on DEPARTMENTS.manager_id = 108 
where 
    department_id = 100 
;

的问题是，我认为甲骨文应该有抱怨的department_id在不确定性where子句，因为它是表employees和departments中的一列。事实是在Oracle 10g中，事实并非如此，结果表明它将department_id解释为departments中的那个。但是，如果我注释掉第二条连接语句（上面的第四行），Oracle会按预期抱怨“ORA-00918：列含糊不清”。

那么，有人可以帮助解释Oracle 10g中如何定义歧义吗？或者这可能是10g中的一个错误？

顺便提一句：这些表是在Oracle 10g捆绑的默认HR模式中定义的。

更新：刚刚发现了一个相关的帖子： Why does Oracle SQL mysteriously resolve ambiguity in one joins and does not in others

来源

2011-06-09 Sapience

也许是因为它是唯一没有别名的人。所以一切都没有“”。在面前首先被视为来自部门的东西。当你给部门别名时，你会得到ORA错误吗？ – 2011-06-09 13:17:04

使用11gr2我不能重新创建（总是得到ORA-00918）。也许试试Beta 11gR2 XE，看看你是否可以重新创建。听起来像一个bug – Harrison 2011-06-09 13:51:36

@致命的别名不解决这个谜。 'SELECT * 从员工的经理加入员工工人在MANAGER.EMPLOYEE_ID = WORKER.MANAGER_ID 上depts.manager_id参加部门科指南= 108 其中部门标识= 100 ;' – Sapience 2011-06-09 13:55:38

我相信这是Oracle选择不修复Oracle 10g中的一个错误。当我们将应用程序从10g升级到11gR2时，我们发现了几个针对不明确的列名称“松散地”写入但在Oracle 10g中工作的查询。他们都在11gR2停止工作。我们联系了Oracle，但他们几乎都表示，对含糊不清的列名的宽容行为对于Oracle 10g是一种正确的行为，而严格的行为对于11g来说是正确的行为。

来源

2011-06-09 14:44:06 Olaf

10g中的正确行为？有人@甲骨文正在吹烟。 – 2011-06-09 16:44:09

@SShannon Severance：他们试图将每个人都转移到11g和11gR2。我相信从7月1日开始，选择坚持10g的被许可人将不得不提高到更高层次的支持，并相应地支付更高的许可费用。 – Olaf 2011-06-09 18:54:01

它固定在10g的某些版本中。有关特定的Oracle支持参考和受影响的版本，请参阅我对另一个类似问题的回答：http://stackoverflow.com/a/4306406/4632 – 2012-05-10 18:24:00

我想是的，因为部门有没有alias。因此，没有被<alias>.限定的所有东西首先被视为从departments。

所以我也认为，当你给departments一个别名时，你应该再次获得ORA-00918。这里不能测试...

来源

2011-06-09 13:36:26

我刚刚测试过，这不是原因，即使我给部门别名，它显示相同的结果没有错误。 – Sapience 2011-06-09 13:52:20

为什么Oracle 10g不会抱怨列不明确？

回答

相关问题