Hi Julian, thanks for the reply. It's definitely not causing incorrect behavior and I guess it's better to leave it as is, since it may break other users code. If we'll return in SqlOperator.createCall SqlInsert instead SqlBasicCall class cast exception may occur for those who casted SqlCall to SqlBasicCall.
Kind regards Arina On Tue, Feb 7, 2017 at 2:10 AM, Julian Hyde <[email protected]> wrote: > SqlOperator.createCall seems to be called mainly from SqlNode.clone, and > that only tends to be called for expressions. > > Ideally SqlInsert should have a createCall method but it’s not high > priority unless it is causing incorrect behavior. Likewise SqlMerge, > SqlUpdate, SqlDelete. > > SqlCreate, SqlDrop, SqlAlter are abstract and do not even have their own > operators so it’s not possible to fix them. > > Julian > > > > On Feb 2, 2017, at 8:09 AM, Arina Yelchiyeva <[email protected]> > wrote: > > > > Hi all, > > > > I have noticed that for example, for SqlExplain > > SqlSpecialOperator.createCall [1] method is overridden but for SqlInsert > > [2] it is not. Thus in case with SqlExplain OPERATOR createCall returns > > SqlCall instance that can be cast to SqlExplain but in case of SqlInsert > > createCall returns SqlCall that can be cast only to SqlBasicCall (and I > > can't take advantage of SqlInsert methods). > > > > So I wanted to ask is there is any particular reason why some nodes do > have > > createCall method overridden and some don't? And in case of SqlInsert > > should it be fixed or not? > > > > [1] > > https://github.com/apache/calcite/blob/92b3d381de4c0f6670cff06d54ce06 > b8231e6684/core/src/main/java/org/apache/calcite/sql/SqlExplain.java#L31 > > [2] > > https://github.com/apache/calcite/blob/02752fe78f817ed317b8873d2f4c7b > 79bfe8b9b5/core/src/main/java/org/apache/calcite/sql/SqlInsert.java#L31 > > > > Kind regards > > Arina > >
