[
https://issues.apache.org/jira/browse/TRAFODION-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339463#comment-16339463
]
ASF GitHub Bot commented on TRAFODION-2840:
-------------------------------------------
Github user zellerh commented on a diff in the pull request:
https://github.com/apache/trafodion/pull/1414#discussion_r163894233
--- 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();
--- End diff --
I don't think we should remove the sort requirement from the parent here,
since the FirstN does not itself do any sorting, so whatever the parent needs
will have to be provided by the child. Therefore we need to pass the parent's
requirement on to the child. If what the parent wants is incompatible with what
the FirstN needs (probably not possible in the current design), we'll return
NULL on line 15562, which is what we want.
> 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)
