[
https://issues.apache.org/jira/browse/DERBY-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663980#comment-13663980
]
Dag H. Wanvik commented on DERBY-6221:
--------------------------------------
The reason why this falls over is as follows: Derby believe we are SELECT *
when we are not, cf. this code in
FromBaseTable#generate:
if ( authorizeSYSUSERS ) {
:
**> if (( referencedCols == null ) || // select * from sys.sysusers
results in a null referecedCols
((referencedCols.getLength() >= passwordColNum ) &&
referencedCols.isSet( passwordColNum - 1 ))) {
throw StandardException.newException(..)
This first condition, "referencedCols == null" is fulfilled because the
optimizer has decided to use the index on USERNAME. This means that the access
path result set has only two columns, not four. That is 1) the username from
the index and 2) the rowPosition
The setting of referencedCols happens in FromBaseTable#changeAccessPath ca line
3163 in this line:
The logic in getReferencedFormatableBitSet has this code at the end:
if (colsAdded != index || always) {
return newReferencedCols;
} else {
return null;
}
In this case, colsAdded and index are both 2, and always == false, so null gets
returned. Therefore the test in #generate concludes we have asked for all the
columns (including password), which is not the case.
We could let FromBaseTable#changeAccessPath ask for always returning a bit set
for referenced columns, as
referencedCols =
resultColumns.getReferencedFormatableBitSet(cursorTargetTable, true, false);
but this is dangerous too, for now the test used to detect a reference to the
password columns breaks since it believes there are four columns in the result.
Perhaps we should perform this test prior to modifying the access path.
> Can't select from SYS.SYSUSERS if you use a WHERE clause in the query
> ---------------------------------------------------------------------
>
> Key: DERBY-6221
> URL: https://issues.apache.org/jira/browse/DERBY-6221
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
>
> The following query runs fine:
> SELECT username, lastmodified FROM sys.sysusers;
> ...but the following query raises an exception:
> SELECT username, lastmodified FROM sys.sysusers WHERE USERNAME = 'FRED';
> ...which is
> ERROR 4251E: No one can view the 'SYSUSERS'.'PASSWORD' column.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
