[
https://issues.apache.org/jira/browse/TRAFODION-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339621#comment-16339621
]
ASF GitHub Bot commented on TRAFODION-2840:
-------------------------------------------
Github user DaveBirdsall commented on a diff in the pull request:
https://github.com/apache/trafodion/pull/1414#discussion_r163930862
--- Diff: core/sql/optimizer/OptPhysRelExpr.cpp ---
@@ -15499,6 +15499,95 @@ GenericUtilExpr::synthPhysicalProperty(const
Context* myContext,
return sppForMe;
} // GenericUtilExpr::synthPhysicalProperty()
+// -----------------------------------------------------------------------
+// FirstN::createContextForAChild()
+// The FirstN node may have an order by requirement that it needs to
+// pass to its child context. Other than that, this method is quite
+// similar to the default implementation, RelExpr::createContextForAChild.
+// The arity of FirstN is always 1, so some logic from the default
+// implementation that deals with childIndex > 0 is unnecessary and has
+// been removed.
+// -----------------------------------------------------------------------
+Context * FirstN::createContextForAChild(Context* myContext,
+ PlanWorkSpace* pws,
+ Lng32& childIndex)
+{
+ const ReqdPhysicalProperty* rppForMe =
+ myContext->getReqdPhysicalProperty();
+
+ CMPASSERT(getArity() == 1);
+
+ childIndex = getArity() - pws->getCountOfChildContexts() - 1;
+
+ // return if we are done
+ if (childIndex < 0)
+ return NULL;
+
+ RequirementGenerator rg(child(childIndex), rppForMe);
+
+ if (reqdOrder().entries() > 0)
+ {
+ // replace our sort requirement with that implied by our ORDER BY
clause
+
+ rg.removeSortKey();
+
+ ValueIdList sortKey;
+ sortKey.insert(reqdOrder());
+
+ // Shouldn't/Can't add a sort order type requirement
+ // if we are in DP2
+ if (rppForMe->executeInDP2())
+ rg.addSortKey(sortKey,NO_SOT);
+ else
+ rg.addSortKey(sortKey,ESP_SOT);
+ }
+
+ if (NOT pws->isEmpty())
--- End diff --
I think you're right. Perhaps this is one of those code blocks I copied
from the default implementation that gets executed only when arity > 1? I'll
look into it more carefully and remove this if it is dead code.
> ORDER BY clause on a view circumvents [first n] updatability check
> ------------------------------------------------------------------
>
> Key: TRAFODION-2840
> URL: https://issues.apache.org/jira/browse/TRAFODION-2840
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Affects Versions: 2.3
> Environment: All
> Reporter: David Wayne Birdsall
> Assignee: David Wayne Birdsall
> Priority: Major
>
> The following script fails:
> >>create table t1 (a int not null, b int, primary key (a));
> --- SQL operation complete.
> >>
> >>insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5),(6,6);
> --- 6 row(s) inserted.
> >>
> >>create view v1 as select [first 5] * from t1 order by a;
> --- SQL operation complete.
> >>
> >>create view v2 as select [first 5] * from t1;
> --- SQL operation complete.
> >>
> >>update v1 set b = 6;
> --- 6 row(s) updated.
> >> -- should fail; v1 should be non-updatable
> >>
> >>update v2 set b = 7;
> *** ERROR[4028] Table or view TRAFODION.SEABASE.V2 is not updatable.
> *** ERROR[8822] The statement was not prepared.
> >>-- does fail; v2 is non-updatable (correctly)
> >>
> It seems the presence of the ORDER BY clause in the view definition
> circumvents the [first n] updatability check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
