Repository: dbt-labs/dbt-core

Issue:
[CT-636] [Bug] Postgres unlimited varchar default to varchar(256)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

When using postgres adapter with some varchar typed columns (like when using dbt_utils.type_string()), if you use incremental materialization with sync_new_columns or append_new_columns, or actually anything that will make dbt generate DDL statements, varchars max size defaults to 256 (handler in base/Column.py behaviour when char_size is None). This makes schema evolution impossible when having textual columns defined as {{ dbt_utils.type_string() }}

### Expected Behavior

The original varchar type with no limit should remain as is and not be assigned a 256 default limit, because we don't know the size limit on a varchar without explicit limits. The schema evolution should be possible, with new columns not created as varchar(256)

### Steps To Reproduce

1. Create an incremental model with on_schema_change: sync_all_columns
2. run the model for the first time
3. add a column whose type is {{ dbt_utils.type_string() }} and whose length exceeds 256 characters
4. re-run the model. It will fail because it adds a varchar(256) column

### Relevant log output

```shell
Debug logs for the schema update : 
 "database"."schema"."table":
         Schema changed: True
         Source columns not in target: [<Column col1 (character varying(256))>, <Column col2 (character varying(256))>, <Column col3 (character varying(256))>]
         Target columns not in source: [<Column col4 (character varying(256))>]
         New column types: []
(Note that all these columns are typed are varchar initially not varchar(256))
Postgres columns data check : 
```
```sql
select
          column_name,
          data_type,
          character_maximum_length,
          numeric_precision,
          numeric_scale

      from "production-data-warehouse".INFORMATION_SCHEMA.columns
      where table_name = '{{table}}'
        
        and table_schema = '{{schema}}'
        
      order by ordinal_position
```
```shell
Error: 
`value too long for type character varying(256)`
```


### Environment

```markdown
- OS: Any
- Python: 3.9-slim
- dbt: 1.0.0
```


### What database are you using dbt with?

postgres

### Additional Context

I already found out why it worked like that, and if validated will be happy to submit a PR (linked to the fact that the way postgres columns are retrieved have NULL info regarding varchar columns max_length, and thus when using it it falls back in default Column handler)
Just wondered if this shall be fixed in the PostgresColumn class (that already handles text columns this way), or if we shall just update the dbt_utils.string_type macro to use text instead of varchar for postgres


Discussion:

Resolving patch:
diff --git a/plugins/postgres/dbt/adapters/postgres/relation.py b/plugins/postgres/dbt/adapters/postgres/relation.py
--- a/plugins/postgres/dbt/adapters/postgres/relation.py
+++ b/plugins/postgres/dbt/adapters/postgres/relation.py
@@ -26,7 +26,9 @@ def relation_max_name_length(self):
 class PostgresColumn(Column):
     @property
     def data_type(self):
-        # on postgres, do not convert 'text' to 'varchar()'
-        if self.dtype.lower() == "text":
+        # on postgres, do not convert 'text' or 'varchar' to 'varchar()'
+        if self.dtype.lower() == "text" or (
+            self.dtype.lower() == "character varying" and self.char_size is None
+        ):
             return self.dtype
         return super().data_type


Test patch: