Use sql instead of compiled_code within the default get_limit_sql macro

[dbeatty10]

resolves #370

Problem

#249 (comment)

@VersusFacit and @mikealfare Looks like this line should be using the function parameter {{ sql }}. It works with {{ compiled_code }} I assume because of the context being set in the get_show_sql macro, but that's likely hiding a future bug.

I could be wrong, but ran into this when providing a custom version of get_show_sql in my project.

Solution

Just swap out sql for compiled_code.

Checklist

• I have read the contributing guide and understand what's expected of me
• I have run this code in development, and it appears to resolve the stated issue
• Tests are not required/relevant for this PR
• This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc.)

[VersusFacit]

Interesting code change 🤔

Before we merge something like this, can we get some downstream CI builds from concrete adapters that show this is correct? Adapters itself doesn't have the functional tests to give us confidence

[dbeatty10]

@VersusFacit Assuming something like this will do the trick?

[dbeatty10]

@VersusFacit Assuming something like this will do the trick?

Assuming so, opened this draft PR to run tests against this branch: dbt-labs/dbt-postgres#178

Does something similar need to be done on adapters other than dbt-postgres? Or is this sufficient?

[dbeatty10]

@VersusFacit all checks on dbt-postgres passed on dbt-labs/dbt-postgres#178 -- see below for screenshot.

Does something similar need to be done on adapters other than dbt-postgres? Or is this sufficient?

[amychen1776]

@dbeatty10 are you able to test this out on other adapters too? That would give me more confidence

[dbeatty10]

@amychen1776 no prob here ya go:

• https://github.com/dbt-labs/dbt-postgres/actions/runs/12281200070
• https://github.com/dbt-labs/dbt-redshift/actions/runs/12279664404
• https://github.com/dbt-labs/dbt-bigquery/actions/runs/12279939150
• https://github.com/dbt-labs/dbt-snowflake/actions/runs/12279964774
• https://github.com/dbt-labs/dbt-spark/actions/runs/12279965582

Process

1. Open each of these links:
   • https://github.com/dbt-labs/dbt-postgres/actions/workflows/integration-tests.yml
   • https://github.com/dbt-labs/dbt-redshift/actions/workflows/integration.yml
   • https://github.com/dbt-labs/dbt-bigquery/actions/workflows/integration.yml
   • https://github.com/dbt-labs/dbt-snowflake/actions/workflows/integration.yml
   • https://github.com/dbt-labs/dbt-spark/actions/workflows/integration.yml
2. Open the "Run workflow" drop down
3. Fill out the following info (placing dbt-adapters-372 (free-form descriptive label) & dbeatty/fix-370 (the branch name of this PR) in the right spots):
   
4. Click the "Run workflow" button to submit
5. Click on the workflow run once it is dispatched to see the details
   
6. Copy the URL of the workflow run into this PR
   e.g., https://github.com/dbt-labs/dbt-snowflake/actions/runs/12279964774

Note

https://github.com/dbt-labs/dbt-postgres/actions/workflows/integration.yml was not found for dbt-postgres, so that will needs some follow-up to standardize. But this is covered by dbt-labs/dbt-postgres#178 for now. See dbt-labs/dbt-postgres#181 for proposed fix.

[VersusFacit]

waiting on CI:

https://github.com/dbt-labs/dbt-redshift/actions/runs/12404226747 ✅
https://github.com/dbt-labs/dbt-bigquery/actions/runs/12404234670 ✅
https://github.com/dbt-labs/dbt-postgres/actions/runs/12404248494 ✅
https://github.com/dbt-labs/dbt-snowflake/actions/runs/12404258382 ✅
https://github.com/dbt-labs/dbt-spark/actions/runs/12404273798 ✅

[VersusFacit]

all CI passed. Thanks for your patience @dbeatty10 . I stayed on late to squeeze this in for the last pre-holiday release after we left you hanging ❤️