[CT-3086] [Feature] Add "name" to Postgres index configuration

[pscanlon1]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

Can we add the "name" config to Postgres index configuration in DBT? I have been using it but when it creates a hashed index name, it fails when I try and combine this with hasura. I would like to override the default index config to supply my own unique name for an index.

Describe alternatives you've considered

Writing a script that runs after DBT runs to rename the index

Who will this benefit?

everyone using Postgres and graphql

Are you interested in contributing this feature?

I could try with some direction

Anything else?

No response

[dbeatty10]

We'd be open to your suggestion to making the name of an index configurable @pscanlon1.

I'm labeling this as help_wanted to indicate that we're reserving this for you or another community member to submit a PR to implement this feature request.

I created a proof-of-concept for some of the relevant code changes in dbt-labs/dbt-core#8656 (which also describes a couple key test cases).

You can create own PR using it as a guide.

The most time-consuming part is likely to be implementing the relevant functional tests.

[bdewilde]

I have a related feature request (implementation-wise), though for different reasons: Postgres indexes have other configurable options besides name, columns, uniqueness, and type, and they are super useful in certain cases. In my case, I've sometimes needed to specify the "nulls [not] distinct" and "where" options, which aren't available via dbt's model "indexes" config, so have had to find workarounds. Would dbt-postgres be interested in supporting additional index configuration, or are y'all trying to limit the complexity here? Thanks for your consideration! 🙇‍♂️

[dbeatty10]

@bdewilde in general, we prefer to limit complexity wherever possible. But we're also trying to enable & empower where it's practical. So often a tricky set of trade-offs!

We'd be open to consider specifying the "nulls [not] distinct" and "where" options, etc. if you are willing to open up separate issue(s) for them (including describing any workarounds you've utilized instead).

That said, expanding configuration of indexes in dbt-postgres isn't very high on our list and we might not be able to assess those feature requests in a timely manner.