[
https://issues.apache.org/jira/browse/CALCITE-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868436#comment-17868436
]
Mihai Budiu commented on CALCITE-6372:
--------------------------------------
I have a working implementation which I plan to submit as a PR with multiple
commits. I don't know if there is any standard proposal for ASOF, I have based
my design on the Snowflake ASOF JOIN documentation referred above.
DuckDB has a very different design:
https://duckdb.org/docs/guides/sql_features/asof_join.html, which is better in
some respects, and worse in others.
My implementation is in core, I don't think it can be just in Babel, it needs
to modify too many core classes.
Snowflake introduces a new keyword MATCH_CONDITION and puts some important
constraints on the shape of both join conditions. DuckDB keeps the traditional
syntax and I imagine infers the two conditions from the existing one.
Snowflake makes the ASOF join always a LEFT join, whereas DuckDB gives you a
choice.
I my implementation I am using MATCH_CONDITION (like Snowflake) and allowing
users to specify LEFT (like DuckDB).
I would appreciate suggestions. Unfortunately these two design choices are
incompatible, so I don't think we can accommodate both.
> Support ASOF joins
> ------------------
>
> Key: CALCITE-6372
> URL: https://issues.apache.org/jira/browse/CALCITE-6372
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.36.0
> Reporter: Mihai Budiu
> Assignee: Mihai Budiu
> Priority: Minor
>
> Seems that this new kind of JOIN named AS OF is very useful for processing
> time-series data. Here is some example documentation from Snowflake:
> https://docs.snowflake.com/en/sql-reference/constructs/asof-join
> The semantics is similar to a traditional join, but the result always
> contains at most one record from the left side, with the last​ matching
> record on the right side (where "time" is any value that can be compared for
> inequality). This can be expressed in SQL, but it looks very cumbersome,
> using a JOIN, a GROUP BY, and then an aggregation to keep the last value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
