> The case there is that "correlation variables" are added to the Logical* nodes (e.g. LogicalFilter, LogicalProject).
BTW, "correlation variables" were added to a LogicalFilter in CALCITE-816. So what is wrong with CALCITE-3183? вт, 14 дек. 2021 г. в 01:24, Konstantin Orlov <kostyaorlo...@gmail.com>: > Vladimir, could you please clarify in what way the PR#2623 changes > the semantics? > > The correlated project is already possible in the master. The MongoProject > already discards variablesSet (simply because it's currently not stored > for > project node) and either fails or returns invalid results. This behavior > (alas, > incorrect) will be preserved after this patch. > > пн, 13 дек. 2021 г. в 17:55, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com>: > >> Hi, >> >> It turns out Calcite's nodes can change semantics without notification for >> the end-users. >> >> Here are the release notes for Calcite 1.21, and it says **nothing** like >> "Ensure you handle Filter#variablesSet in case you implement Filter or in >> case you transform LogicalFilter in your rules" >> https://calcite.apache.org/news/2019/09/11/release-1.21.0/ >> >> On top of that, the in-core adapters fail to handle that properly. For >> example, MongoFilter discards Filter#variablesSet. >> >> Can we please stop changing the semantics of RelNodes or can we have a >> better way to detect the changes in the client code? >> >> What if we add a "version" property to the corresponding RelNodes, and we >> increment it every time the semantic changes? >> Then client APIs could be coded like "ok, I'm prepared to handle Project >> v4, and Filter v5" (e.g. make "version" required when registering a rule), >> and there will be a runtime error in case Calcite generates Filter v6 in >> runtime. >> >> --- >> >> Sample case: >> CALCITE-3183 Trimming method for Filter rel uses wrong traitSet >> CALCITE-4913 Correlated variables in a select list are not deduplicated >> >> The case there is that "correlation variables" are added to the Logical* >> nodes (e.g. LogicalFilter, LogicalProject). >> Unfortunately, that change is hard to notice: there's no compilation >> failure, and there's no runtime error. >> >> The old client code just discards "correlation variables", and I guess it >> would result in wrong results or something like that. >> Silent wrong results is a really sad outcome from the database. >> >> CALCITE-4913 / PR#2623 adds Project#variablesSet property as well, and I >> guess it would in the same hidden semantic loss. >> >> Vladimir >> > > > -- > Regards, > Konstantin Orlov > -- Regards, Konstantin Orlov
