[DERBY-5292] SQLAuthorisation and views

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2
• Fix Version/s: 10.8.2.2, 10.9.1.0
• Component/s: SQL
• Environment: windows xp
• Urgency: Normal
• Issue & fix info: Repro attached
• Bug behavior facts: Deviation from standard, Security, Seen in production
• Assignee: Dag H. Wanvik
• Reporter: Thomas Hill
• Created: 22/Jun/11 17:05
• Updated: 17/Jun/13 09:19
• Resolved: 04/Jul/11 11:58

Description

Hi,

in some cases there seem to be issues with SQLAuthorisation in conjunction with database VIEWS.
Please see attached files as repro (script.txt has only the SQL I executed, output is the output resulting when running the script).
I would think identical results should be returned in all cases and independent on how the view has been defined, but this to my surprise not being the case:

1) Trying to select from view appl."VW_MyTasks" - which is a simple view defined on just one table - leads to expected results, i.e. "my" tasks are being returned.
2) Trying to select from view appl."VW_MyPriorityTasks - which is a view defined on two joined tables without using an inner join clause - leads to expected results, i.e. "my" priority tasks are being returned.
3) Trying to select from view appl."VW2_MyPriorityTasks - which is the same view but now the two tables joined using an inner join clause - leads to an error and no tasks returned (when the same results as in 2) above were expected).
4) Trying to select from view appl."VW3_MyPriorityTasks" - which is a view defined using a subselect - also unexpectedly leads to an error.

Note: While I could rewrite each inner join clause with changing the syntax like in 2) above, this provides a simple work-around for such cases. May be there is a work-around for subselects also (not sure if every subselect could be rewritten to a join?). However when depending on using EXISTS constructs in the query there unfortunately is no way (I would know of) to get around this problem. Unfortuanetly a view that makes use of EXISTS is also one I would need to define in my data base...

Thanks