rubenada commented on code in PR #2962:
URL: https://github.com/apache/calcite/pull/2962#discussion_r1039714696
##########
core/src/main/java/org/apache/calcite/runtime/SpatialTypeFunctions.java:
##########
@@ -1318,6 +1322,195 @@ public static Geometry ST_Translate(Geometry geom,
BigDecimal x, BigDecimal y) {
return transformation.transform(geom);
}
+ // Geometry measurement functions
+
+ /**
+ * Returns the area of the {@code geom}.
+ */
+ public static @Nullable Double ST_Area(Geometry geom) {
+ return geom.getArea();
Review Comment:
Yes, you're right.
If I am not mistaken, the "magic" happens because the
`SpatialTypeFunctions.java` class uses `@Strict` annotation, which means all
its methods will have
[NullPolicy.STRICT](https://github.com/apache/calcite/blob/33ca193095fcd0db46b88a270bca8d8cd569b31a/core/src/main/java/org/apache/calcite/adapter/enumerable/NullPolicy.java#L31)
via
[ScalaFunctionImpl#getNullPolicy](https://github.com/apache/calcite/blob/33ca193095fcd0db46b88a270bca8d8cd569b31a/core/src/main/java/org/apache/calcite/schema/impl/ScalarFunctionImpl.java#L171)
and this null policy means that the function "Returns null if and only if one
of the arguments are null", so with this information Calcite will generate the
null-check-related code before actually reaching the specific
SpatialTypeFunctions.ST_* implementation.
To sum up, yes, I think the current code (without null check) is correct.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
