Feat: add macro get_query_results_as_single_value

[CR-Lough]

resolves #617

This is a:

• documentation update
• bug fix with no breaking changes
• new functionality
• a breaking change

All pull requests from community contributors should target the main branch (default).

Description & motivation

Checklist

• [ x ] This code is associated with an Issue which has been triaged and accepted for development.
• [ x ] I have verified that these changes work locally on the following warehouses (Note: it's okay if you do not have access to all warehouses, this helps us understand what has been covered)
  • BigQuery
  • [ x ] Postgres
  • Redshift
  • [ x ] Snowflake
• I followed guidelines to ensure that my changes will work on "non-core" adapters by:
  • [ x ] dispatching any new macro(s) so non-core adapters can also use them (e.g. the star() source)
  • [ x ] using the limit_zero() macro in place of the literal string: limit 0
  • using dbt.type_* macros instead of explicit datatypes (e.g. dbt.type_timestamp() instead of TIMESTAMP
• I have updated the README.md (if applicable)
• [ x ] I have added tests & descriptions to my models (and macros if applicable)
• I have added an entry to CHANGELOG.md

[joellabes]

This is cool! Thanks @CR-Lough, I'll try to review this week 🤞

[joellabes]

Thanks for taking the initiative to move this forward @CR-Lough!

No complaints with how the code you've written works, but a few concerns about the specific implementation choices. Let me know what you think - if you've got a specific vision in mind then I'm willing to join you on that journey, but if it's there "just in case" then I think we keep it simple and only make it more complex if needed in the future.

[joellabes]

@CR-Lough I'm hoping to cut the release candidate of utils v1 soon and would love to include this - how are you feeling about having time to have a look at the review feedback?

[CR-Lough]

Hey @joellabes , got caught up in Coalesce and the week back at work. I want to finish this up too! Will Sunday evening make the cut? Or will it be too late?

[joellabes]

I am travelling from tomorrow and back on deck next Tuesday (NZ time), so that timing works perfectly 👌 thank you!

[joellabes]

@CR-Lough as you might have seen, I fleshed out some tests today! Pretty happy with how it's looking now, I'll get @dbeatty10 to have a second look though since I'm now too close to it

[dbeatty10]

Awesome to see all these edge cases covered 💪

👍 Approving

---

But while we're here...

If I had ruby red slippers on, I'd close my eyes, click my heels, and ask for new names for both:

• get_query_results_as_dict
• get_query_results_as_single_value

Design aspiration:

• Macro names nearly as terse as run_query, but still sufficiently descriptive.

I don't personally have any great ideas here, although I appreciate the brevity that the Elementary Data folks have with these:

• result_value
• result_row_to_dict
• result_column_to_list

Maybe new names like these?

• single_result or result_singleton
• dict_result or result_dict

'cause probs won't get a ton of love for suggesting anything with monuple or monad in the name. 😂

[joellabes]

ask for new names for both

I was writing a bigger reply on why I wasn't going to change this (mostly around adding extra thrash to an already-thrashy upgrade season), but then realised I could get on board with get_single_value() as a sibling to get_column_values(), so I'm gonna do that, and leave get_query_results_as_dict as a slight outlier.

[joellabes]

Thanks for coming on the journey @CR-Lough! great contribution 🎉

[CR-Lough]

Thank you for seeing it through, @joellabes ! It was an excellent learning experience!

Also thank you @dbeatty10 !