Support the ability to alter table...rename a column

[sfc-gh-dsandler]

As a data modeler, I need to rename a column. I would like to use the snowflake_table resource to support this action

From pure-DDL perspective, it would like this:

alter table mydb.myschema.mytbl rename column col1 to column1;

to be supported with a ne property called OLD_NAME in the nested schema for column (as such):

resource "snowflake_table" "my_tbl" {
  name     = "MYTBL"
  database = "MYDB"
  schema   = "MYSCHEMA"
  column   {
            name = "COLUMN1"
            old_name = "COL1"
            type = "STRING" 
  } 
  comment  = "test table"

  depends_on = [snowflake_schema.schema]
}

[kumarjoshi]

This would be a great feature. Plus, the ability to change data type would be great too.

[juan-yunis]

I would like to see this feature released any time soon!

[mddataminr]

I would love this functionality too. I imagine the issue is maintaining the column id across each iteration. ie, if you change the name, right now TF is going to treat it like a drop and add. However, if the column had on id field, you could change attributes of it without losing the relationship.

The problem with this is that you'd now have a TF field to create with each column that is only valuable occassionally.

resource "snowflake_table" "my_tbl" {
  name     = "MYTBL"
  database = "MYDB"
  schema   = "MYSCHEMA"
  column   {
            id = "column_1_id"
            name = "COLUMN1"
            type = "STRING" 
  } 
  comment  = "test table"

  depends_on = [snowflake_schema.schema]
}

Or maybe we pass in a column resource instead of the current structure? Something like:

resource "snowflake_table" "my_tbl" {
  name     = "MYTBL"
  database = "MYDB"
  schema   = "MYSCHEMA"
  resource "snowflake_column" "column1"   {
            name = "COLUMN1"
            type = "STRING" 
  } 
  comment  = "test table"

  depends_on = [snowflake_schema.schema]
}

I'm not sure if the option above is syntactically possible in TF, but something along either line would be very helpful.

[sagar-raythatha]

I would love to have this feature. I am new to Go language but I would be happy to collaborate with anyone to implement this feature.

[fermezz]

I'd love to see this one go through. Can we make it happen?

[elikschultz]

I am also experiencing issues with this. To add a little more color, the problem extends beyond not being able to alter a column in place, as trying to rename a column can also cause unintended changes to other columns that are not being modified.

For instance, let a resource be created as follows:

resource snowflake_table test_test {
  database            = "MY_DATABASE"
  schema              = "MY_SCHEMA"
  name                = "TEST_1"
  column {
      name = "ABC"
      type = "VARCHAR(16777216)"
  }
  column {
      name = "EFG"
      type = "VARCHAR(16777216)"
  }
}

Now let column ABC be renamed to HIJ:

resource snowflake_table test_test {
  database            = "MY_DATABASE"
  schema              = "MY_SCHEMA"
  name                = "TEST_1"
  column {
      name = "HIJ"
      type = "VARCHAR(16777216)"
  }
  column {
      name = "EFG"
      type = "VARCHAR(16777216)"
  }
}

Terraform will drop ABC and add a column named HIJ, but the next time a terraform plan/terraform apply are run, Terraform will think EFG needs to be renamed to HIJ and that HIJ needs to be renamed to EFG, so ultimately column EFG will end up getting deleted and recreated as well.

I like @mddataminr's suggestions, particularly the first one. Similar to @sagar-raythatha I don't have Go experience but would be contribute in any way I can.

[greenantim]

I would like to see this feature added. If you have a table with a single column and then try to rename the column, terraform apply will fail with an error because it attempts to drop the column which is not allowed when it is the only column in the table.

[franziskakuehn]

schema evolution strategy would be highly appreciated

• rename columns
• control table schema order
• add columns
• version control

[jandanecki]

I noticed similar behaviour like @elikschultz describe.

I have table definition with sth like

  column {
    name     = "aaa"
    type     = "VARCHAR"
    nullable = false
  }
  column {
    name     = "bbb"
    type     = "VARCHAR"
    nullable = false
  }
  column {
    name     = "ccc"
    type     = "VARCHAR"
    nullable = false
  }

and after each plan I see

      ~ column {
          ~ name     = "aaa" -> "ccc"

        }
      ~ column {
            name     = "bbb"

        }
      ~ column {
          ~ name     = "ccc" -> "aaa"
        }

[samoor64]

Please add this feature, would be extremely helpful!

[realanda]

+1; please add this feature -- it would be really helpful!
It's critical for a production table with realistic usecases.
We've run into similar problems described in this thread.

[Sophiakorginska]

+1, having the same issue as @jandanecki. Btw, @jandanecki how are you handling this issue in your terraform code, I have a lot of tables and this behavior overwhelms the output of my terraform plan/apply. Would be glad for any suggestions, thanks!

[reachoutbud]

Bringing this thread back to attention—can this be resolved quickly? We're facing numerous issues due to the lack of this capability.

[sfc-gh-asawicki]

Hey @reachoutbud. We are aware this is still a valid problem and it is on our roadmap: https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#support-object-renaming-properly.

[reachoutbud]

@sfc-gh-asawicki
Could you let me know when it will be available on any specific date?

[sfc-gh-asawicki]

@reachoutbud we do not have any specific date that we can share at the moment.

[sfc-gh-jcieslak]

Hi all 👋
Recently, we've done more in-depth research on a few topics; one of them was ignoring the list item's order after creation and handling individual list item updates. When applied to the table columns, it should solve most (if not all) of the issues. A more detailed summary of the research should be posted (and announced in the discussions) soon, so stay tuned. The fix for table columns should be adjusted with the overall table refactor for v1 (that is marked as an essential object).