findepi commented on code in PR #13372:
URL: https://github.com/apache/datafusion/pull/13372#discussion_r1880110069
##########
datafusion/expr-common/src/signature.rs:
##########
@@ -138,6 +141,48 @@ pub enum TypeSignature {
NullAry,
}
+impl TypeSignature {
+ #[inline]
+ pub fn is_one_of(&self) -> bool {
+ matches!(self, TypeSignature::OneOf(_))
+ }
+}
+
+#[derive(Debug, Clone, Eq, PartialOrd)]
+pub enum TypeSignatureClass {
+ Timestamp,
Review Comment:
> Both systems treat `TIMESTAMP` and `TIMESTAMP WITH TIME ZONE` as distinct
types in the high level.
that's a good point, they are quite different: only the latter denotes point
in time. the former denotes "wall date/time" with no zone information, so does
not denote any particular point in time.
their similarity is deceptive and source of many bugs
> This reduces the likelihood of developers failing to correctly handle
type checks when implementing timestamp functions.
the timestamp and timestamp tz values are different arrow types, so the
function implementor needs to handle them separately anyway
The point is, some functions will be applicable to one of these types but
not the other.
for example, a (hypothetical) `to_unix_timestamp(timestamp_tz) -> Int64`
function should operate on point in time value, so it should accept the
timestamp_tz.
Note that in SQL, timestamp is coercible to timestamp_tz, so such function
is still going to be callable with timestamp value, but that's not something
function implementor should be concerned about.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
