Databricks: Support Timetravel With "TIMESTAMP AS OF"

[JamesVorder]

This PR adds support for Databricks' timstamp-based time travel. This is a first step toward resolvign #2006.

The following is now supported:

SELECT 1 FROM t1 TIMESTAMP AS OF '2018-10-18T22:15:12.013Z';
SELECT 1 FROM t1 TIMESTAMP AS OF CURRENT_TIMESTAMP() - INTERVAL 12 HOURS;
-- etc.

[iffyio]

I think this should use the defined supports_timestamp_versioning?

[JamesVorder]

I think relying on supports_timestamp_versioning alone might be insufficient. Please help me understand the desired behavior, I'm pretty new to the project.

The reason that I think that supports_timestamp_versioning may be insufficient on its own is that if we rely exclusively on that function to decide whether we parse TIMESTAMP AS OF syntax, then it will become available in the BigQuery dialect (and Snowflake, and MSSQL) - incorrectly. This is the reason I added an assertion to the BigQuery time travel test, looking for an error when TIMESTAMP AS OF is used.

In fact, I think what I have in this PR is also insufficient. If I use valid Snowflake time travel syntax (SELECT * FROM tbl AT(TIMESTAMP => '2024-12-15 00:00:00')), it's being accepted by the Databricks dialect. Instead, I would expect the Databricks dialect to throw an error (AT... is not valid time travel syntax in Databricks.)

Please help me understand the desired behavior here. Am I right to expect that an error should be thrown in the cases mentioned?

[JamesVorder]

To demonstrate my thinking here, I've added the following 2 commits, which result in two failing tests:

• b353499 -- sqlparse_bigquery::parse_table_timetravel fails after this commit
• 759406f -- sqlparse_databricks::parse_table_timetravel fails after this commit

Are these failures valid, or is my expectation incorrect?

[iffyio]

Yeah its fine for the parser to be permissive and accept sql statements for a dialect that wouldn't necessarily be supported by the dialect (downstream crates are expected to validate the returned AST if the behavior is undesirable for a specific use case), so that e.g. having bigquery accept the 'TIMESTAMP AS OF' would be fine.

[JamesVorder]

Ah! That makes sense, thank you for explaining. I believe this is addressed by the following 2 commits:

• 21783cc
• 270c41b