[
https://issues.apache.org/jira/browse/DERBY-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546022#comment-13546022
]
Rick Hillegas edited comment on DERBY-6036 at 1/9/13 4:32 PM:
--------------------------------------------------------------
If you wrap a base table in a view, it appears that the projection is not
passed through to the base table. I am attaching derbyAST.xml, which is the
printout of parse(), bind(), and optimize() ASTs produced by the following
script when you use the XmlASTPrinter attached to DERBY-4415. From the
printout, you can see the following:
1) For the SELECT from a base table (select s_nr from t where ns_r = 3000), the
optimizer wraps the base table in a ProjectRestrict node which projects out
only two columns.
2) However, for the SELECT from a view on that base table (select s_nr from vt
where ns_r = 3000), the optimizer wraps the base table in a ProjectRestrict
node which projects out ALL four columns in the table.
Here is the script:
connect 'jdbc:derby:memory:db;create=true';
create function integerList()
returns table( s_r int, s_nr int, ns_r int, ns_nr int )
language java
parameter style derby_jdbc_result_set
no sql
external name
'org.apache.derbyTesting.functionTests.tests.lang.RestrictedVTITest.integerList';
create view vf as select * from table( integerList() ) s;
create table t ( s_r int, s_nr int, ns_r int, ns_nr int );
insert into t values ( 1, 2, 3, 4 ), ( 100, 200, 300, 400 ), ( 1000, 2000,
3000, 4000 ), ( 10000, 20000, 30000, 40000 );
create view vt as select * from t;
create procedure setInspector( visitorClassName varchar( 32672 ) )
language java
parameter style java
modifies sql data
external name 'ASTInspector.setInspector'
;
call setInspector( 'XmlASTPrinter' );
select s_nr from t where ns_r = 3000;
select s_nr from table( integerList() ) s where ns_r = 3000;
select s_nr from vt where ns_r = 3000;
select s_nr from vf where ns_r = 3000;
call setInspector( null );
was (Author: rhillegas):
If you wrap a base table in a view, it appears that the projection is not
passed through to the base table. I am attaching derbyAST.xml, which is the
printout of parse(), bind(), and optimize() ASTs produced by the following
script when you use the XmlASTPrinter attached to DERBY-4415. From the
printout, you can see the following:
1) For the SELECT from a base table (select s_nr from t where ns_r = 3000), the
optimizer wraps the base table in a ProjectRestrict node which projects out
only two columns.
2) However, for the SELECT from a view on that base table (select s_nr from vt
where ns_r = 3000), the optimizer wraps the base table in a ProjectRestrict
node which projects out ALL four columns in the table.
> If you wrap a SELECT * view around a table, all of the columns are read from
> the base row even when you SELECT only a subset of the view columns.
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6036
> URL: https://issues.apache.org/jira/browse/DERBY-6036
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
> Attachments: derby-6036.sql, derbyAST.xml
>
>
> This also affects SELECTs from views wrapping RestrictedVTIs. Restrictions
> are pushed into a restricted VTI if you wrap it in a view. However,
> projections are not. I will attach a script showing this problem.
--
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
