duckdb / dbt-duckdb

dbt (http://getdbt.com) adapter for DuckDB (http://duckdb.org)
Apache License 2.0
788 stars 70 forks source link

Add DATE to dateadd macro #406

Open alittlesliceoftom opened 1 week ago

alittlesliceoftom commented 1 week ago

Fixes #405

tl;dr, helps you avoid errors like:

  Binder Error: Could not choose a best candidate function for the function call "+(STRING_LITERAL, INTERVAL)". In order to select one, please add explicit type casts.        Candidate functions:
        +(DATE, INTERVAL) -> TIMESTAMP
        +(TIME, INTERVAL) -> TIME
        +(TIMESTAMP, INTERVAL) -> TIMESTAMP
        +(TIME WITH TIME ZONE, INTERVAL) -> TIME WITH TIME ZONE
        +(TIMESTAMP WITH TIME ZONE, INTERVAL) -> TIMESTAMP WITH TIME ZONE
        +(INTERVAL, INTERVAL) -> INTERVAL

  LINE 1: /* {"app": "dbt", "dbt_version": "1.7.9", "profile_...
alittlesliceoftom commented 1 week ago

See docs here: https://duckdb.org/docs/sql/functions/date.html

alittlesliceoftom commented 1 week ago

I didn't have time to setup integration tests, but tested the updated macro locally, and 'correct' example now works:

SELECT {{ dateadd(datepart="month", interval=1, from_date_or_timestamp="'2021-08-12'") }} AS period_of_load

jwills commented 1 week ago

yeah I'm surprised this didn't break on the regular unit tests-- like, does this not work anymore and I missed it? https://github.com/dbt-labs/dbt-adapters/blob/main/dbt-tests-adapter/dbt/tests/adapter/utils/fixture_dateadd.py

alittlesliceoftom commented 1 week ago

Possibly those are more explicit strings? So inference can work?

jwills commented 1 week ago

My concern here is what happens if I pass in a TIMESTAMP instead of a string or a DATE? Or a string that should be cast as a TIMESTAMP instead?

alittlesliceoftom commented 1 week ago

Yeh... Interestingly in DuckDb the dateadd operations seem to expect the coder to know and set the type ahead of time in the statement? https://duckdb.org/docs/sql/functions/interval