Postgres: Prevent temp relation identifiers from being too long

[elexisvenator]

related #2197

Description

The currently postgres make_temp_relation adds a 29 character suffix to the end of the temp relation identifier (9 from default suffix and 20 from timestamp). This is a problem now that relations with more than 63 characters raise exceptions.
The fix is to shorten the suffix and also trim the base_relation identifier so that the total length is always less than 63 characters.

An exception can also be raised if the default suffix is overridden with a value that is too long.

Checklist

• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

[jtcohen6]

Thanks for this PR, @elexisvenator! Really cleverly done. This will enable us to say, once and for all, that 63 is the number we shall count, and the number of the counting shall be 63, regardless of materialization type.

Quick bits before we can merge this:

1. Can you add a changelog note?
2. I would have expected a failing test here. (More specifically, a pass where we don't expect it.) Could you take a quick look at 063_relation_name_tests and adjust so that we can test for (a) passage when a postgres incremental model name is ~60 chars (thanks to this PR), (b) failure when a postgres model name is itself >63 chars?

[jtcohen6]

I hesitate about replacing one silent truncation (by postgres) with another (by dbt), but I suppose this is only for temp relation naming, for use mid-materialization, and it won't have any effect on how users actually reference the final model

[elexisvenator]

This will enable us to say, once and for all, that 63 is the number we shall count, and the number of the counting shall be 63, regardless of materialization type.

Almost, the actual limit is 51 due to most materializations creating persisted backup tables with the suffix __dbt_backup

I will add the changes tonight 👍

[jtcohen6]

Almost, the actual limit is 51 due to most materializations creating persisted backup tables with the suffix __dbt_backup
make_temp_relation

Yes, that's silly and certainly for historical reasons. We should just use make_temp_relation in the table and view materializations as well, rather than rehashing all the logic for tmp_identifier and intermediate_relation.

If that's a change you wanted to address in this PR, I'd support it. You certainly don't have to, though, it's at the edge of the scope.

[elexisvenator]

I'm less certain about touching backup tables. They are persisted and I frequently see them continuing to exist especially if dbt fails for some reason during a run. If they have a unique generated name then it wouldn't be possible to clean these up automatically.

[jtcohen6]

Ok, that's a fair point. I wouldn't want to give globally unique names to backup_relation, only to intermediate_relation, but there's still the matter of the suffix length. I'd like to give this more dedicated thought, but I think that's going to be a while from now, when it's finally necessary and proper to clean up our builtin materializations.

For the time being, then, 51 shall be the order of the day.

[elexisvenator]

I updated the integration tests to check up to 51 characters, and do a separate check that triggers make_temp_relation in an incremental model. There is also a skipped test that would pass if a way to deal with the __dbt_backup is found.

[jtcohen6]

Thank you so much for this contribution @elexisvenator!