[BUG] Column Escaping Doesn't Work with NOT Well

[ahuangpod]

Describe the bug
Now dbtvault wraps all the columns with quotes, but not would be in the quotes as well.

Versions

dbt: 1.0.4
dbtvault: 0.8.2

To Reproduce

 {{
     dbtvault.stage(
         source_model = "source_model",
         hashed_columns = {
             "hk_a": "id",
             "a_hashdiff": {
                 "is_hashdiff": true,
                 "columns": [
                     "a",
                 ]
             }
         },
         derived_columns = {
             "derived_column_a": "not column_a",
         },
     )
 }}

The compiled SQL would be like:

derived_columns AS (
    SELECT

    "not column_a" AS "eff_flag",

   FROM source_data
),

Expected behavior
The not should be outside the quotes like:

derived_columns AS (
    SELECT

    not "column_a" AS "eff_flag",

   FROM source_data
),

Screenshots
If applicable, add screenshots to help explain your problem.

Log files
If applicable, provide dbt log files which include the problem.

Additional context
Add any other context about the problem here.

[ahuangpod]

Do we have any updates on this?

BTW, here is the macro:

 {%- macro default__escape_column_name(column) -%}

     {%- set escape_char_left  = var('escape_char_left',  '"') -%}
     {%- set escape_char_right = var('escape_char_right', '"') -%}

     {%- set escaped_column_name = escape_char_left ~ column | replace(escape_char_left, '') | replace(escape_char_right,  '') | trim ~ escape_char_right -%}

     {%- do return(escaped_column_name) -%}

 {%- endmacro -%}

Thank you.

[DVAlexHiggs]

Hi, thank you for your report! Sorry for the delayed response.

There's a few other cases I can think of where the quoting will cause problems and we'll want to make sure our existing tests cover those.

[DVAlexHiggs]

We're thinking of implementing this by removing quoting from derived columns by default, and adding it as a configuration option per derived column.

This would allow more or less normal functionality and provide the means for people to solve issues with reserved words and spaces if needed in hopefully, less common cases (this was the original reason we introduced escaping/quoting in the first place)

Thoughts on this?

[DVAlexHiggs]

Something like this:

derived_columns:
  BOOKING_TYPE: {
    source_column: "TYPE",
    escape: true
  }
 # OR
 derived_columns:
  BOOKING_TYPE: "TYPE"

[ahuangpod]

Thank you, I think that looks good to me. Making it configurable would be useful.

[DVAlexHiggs]

Fix released in v0.9.0. Let us know if you continue to have issues. Thanks!