O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # ALTER TABLE APPEND Move dados de uma tabela de origem existente para acrescentar linhas a uma tabela de destino. Os dados da tabela de origem são movidos para as colunas correspondentes na tabela de destino. A ordem das colunas não importa. Depois que os dados forem acrescentados com sucesso na tabela de destino, a tabela de origem fica vazia. ALTER TABLE APPEND geralmente é muito mais rápido do que as operações [CREATE TABLE AS](r_CREATE_TABLE_AS.md) ou [INSERT](r_INSERT_30.md) semelhantes, pois os dados são movidos, não duplicados. **nota** ALTER TABLE APPEND move blocos de dados entre a tabela de origem e uma tabela de destino. Para melhorar a performance, ALTER TABLE APPEND não compacta o armazenamento como parte da operação de append. Como resultado, o uso do armazenamento aumenta temporariamente. Para recuperar o espaço, execute uma operação [VACUUM](r_VACUUM_command.md). Colunas com o mesmo nome também devem ter atributos de coluna idênticos. Se a tabela de origem ou a tabela de destino tiver colunas que não existem na outra tabela, use os parâmetros IGNOREEXTRA ou FILLTARGET para especificar como as colunas extras devem ser gerenciadas. Não é possível acrescentar uma coluna de identidade. Se ambas as tabelas incluírem uma coluna de identidade, o comando falhará. Se somente uma tabela tiver uma coluna de identidade, inclua o parâmetro FILLTARGET ou IGNOREEXTRA. Para obter mais informações, consulte [Observações de uso de ALTER TABLE APPEND](#r_ALTER_TABLE_APPEND_usage). É possível associar uma coluna GENERATED BY DEFAULT AS IDENTITY. Você pode atualizar as colunas definidas como GENERATED BY DEFAULT AS IDENTITY com os valores fornecidos. Para obter mais informações, consulte [Observações de uso de ALTER TABLE APPEND](#r_ALTER_TABLE_APPEND_usage). A tabela de destino deve ser uma tabela permanente. No entanto, a origem pode ser uma tabela permanente ou uma visão materializada configurada para ingestão de streaming. Os objetos devem usar o mesmo estilo de distribuição e a mesma chave de distribuição, caso definidos. Se os objetos estiverem classificados, ambos devem usar o mesmo estilo de classificação e definir as mesmas colunas como chaves de classificação. Um comando ALTER TABLE APPEND é confirmado automaticamente logo depois da conclusão da operação. O comando não pode ser revertido. Não é possível executar ALTER TABLE APPEND em um bloco de transações (BEGIN ... END). Para obter mais informações sobre transações, consulte [Níveis de isolamento no Amazon Redshift](c_serial_isolation.md). ## Privilégios obrigatórios Dependendo do comando ALTER TABLE APPEND, é necessário um dos seguintes privilégios: + Superusuário + Usuários com o privilégio de sistema ALTER TABLE + Usuários com os privilégios DELETE e SELECT na tabela de origem e com o privilégio INSERT na tabela de destino ## Sintaxe ``` ALTER TABLE target_table_name APPEND FROM [ source_table_name | source_materialized_view_name ] [ IGNOREEXTRA | FILLTARGET ] ``` A anexação com base em uma visão materializada funciona somente no caso em que a visão materializada está configurada para [Ingestão de streaming para uma visão materializada](materialized-view-streaming-ingestion.md). ## Parâmetros *nome\_tabela\_destino* Nome da tabela à qual as linhas são acrescentadas. Especifique somente o nome da tabela ou use o formato *schema\_name.table\_name* para adotar um esquema específico. A tabela de destino deve ser uma tabela permanente existente. FROM *nome\_tabela\_origem* Nome da tabela que fornece as linhas que serão acrescentadas. Especifique somente o nome da tabela ou use o formato *schema\_name.table\_name* para adotar um esquema específico. A tabela de origem deve ser uma tabela permanente existente. FROM *source\_materialized\_view\_name* O nome da visão materializada que fornece as linhas que serão anexadas. A anexação com base em uma visão materializada funciona somente no caso em que a visão materializada está configurada para [Ingestão de streaming para uma visão materializada](materialized-view-streaming-ingestion.md). A visão materializada de origem já deve existir. IGNOREEXTRA Palavra-chave que especifica se a tabela de origem inclui colunas que não constam na tabela de destino. Os dados nas colunas extras devem ser descartados. Não é possível usar IGNOREEXTRA com FILLTARGET. FILLTARGET Palavra-chave que especifica se uma tabela de destino inclui colunas que não constam na tabela de origem. As colunas devem ser preenchidas com o valor [DEFAULT](r_CREATE_TABLE_NEW.md#create-table-default) de coluna, caso haja um valor definido, ou com NULL. Não é possível usar IGNOREEXTRA com FILLTARGET. ## Observações de uso de ALTER TABLE APPEND + ALTER TABLE APPEND move somente colunas idênticas da tabela de origem para a tabela de destino. A ordem das colunas não importa. + Se a tabela de origem ou de destino tiver colunas extras, use FILLTARGET ou IGNOREEXTRA de acordo com as seguintes regras: + Se a tabela de origem tiver colunas inexistentes na tabela de destino, inclua IGNOREEXTRA. O comando ignora as colunas extras na tabela de origem. + Se a tabela de destino tiver colunas inexistentes na tabela de origem, inclua FILLTARGET. O parâmetro preenche as colunas extras na tabela de destino com valores padrão de coluna ou com o valor IDENTITY, caso haja um valor definido, ou com NULL. + Se as tabelas de origem e de destino tiverem colunas extras, o comando falhará. Não é possível usar FILLTARGET e IGNOREEXTRA. + Se uma coluna com o mesmo nome, porém atributos diferentes, for encontrada em ambas as tabelas, o comando falhará. Colunas de mesmo nome devem ter os atributos a seguir em comum: + Tipo de dados + Tamanho da coluna + Codificação de compactação + Não nulo + Estilo de classificação + Colunas de chave de classificação + Estilo de distribuição + Colunas de chave de distribuição + Não é possível acrescentar uma coluna de identidade. Se as tabelas de origem e de destino tiverem colunas de identidade, o comando falhará. Se somente a tabela de origem tiver uma coluna de identidade, inclua o parâmetro IGNOREEXTRA para ignorar a coluna de identidade. Se somente a tabela de destino tiver uma coluna de identidade, inclua o parâmetro FILLTARGET para que a coluna de identidade seja preenchida de acordo com a cláusula IDENTITY definida para a tabela. Para obter mais informações, consulte [DEFAULT](r_CREATE_TABLE_NEW.md#create-table-default). + É possível associar uma coluna de identidade padrão com a instrução ALTER TABLE APPEND. Para obter mais informações, consulte [CRIAR TABELA](r_CREATE_TABLE_NEW.md). + As operações ALTER TABLE APPEND mantêm bloqueios exclusivos quando executadas em visões materializadas de streaming do Amazon Redshift conectadas a qualquer um dos seguintes: + Um Amazon Kinesis data stream + Um tópico Amazon Managed Streaming for Apache Kafka + Um stream externo compatível, como um tópico do Confluent Cloud Kafka Para obter mais informações, consulte [Ingestão de streaming para uma visão materializada](materialized-view-streaming-ingestion.md). ## Exemplos de ALTER TABLE APPEND Digamos que sua organização mantém uma tabela, SALES\_MONTHLY, para capturar as transações de vendas atuais. Você deseja mover dados da tabela de transações para a tabela SALES todos os meses. É possível usar os comandos INSERT INTO e TRUNCATE a seguir para realizar a tarefa. ``` insert into sales (select * from sales_monthly); truncate sales_monthly; ``` No entanto, você pode realizar a mesma operação de maneira muito mais eficiente usando o comando ALTER TABLE APPEND. Em primeiro lugar, consulte a [PG\_TABLE\_DEF](r_PG_TABLE_DEF.md) tabela de catálogo do sistema para verificar se ambas as tabelas têm as mesmas colunas com atributos de coluna idênticos. ``` select trim(tablename) as table, "column", trim(type) as type, encoding, distkey, sortkey, "notnull" from pg_table_def where tablename like 'sales%'; table | column | type | encoding | distkey | sortkey | notnull -----------+------------+-----------------------------+----------+---------+---------+-------- sales | salesid | integer | lzo | false | 0 | true sales | listid | integer | none | true | 1 | true sales | sellerid | integer | none | false | 2 | true sales | buyerid | integer | lzo | false | 0 | true sales | eventid | integer | mostly16 | false | 0 | true sales | dateid | smallint | lzo | false | 0 | true sales | qtysold | smallint | mostly8 | false | 0 | true sales | pricepaid | numeric(8,2) | delta32k | false | 0 | false sales | commission | numeric(8,2) | delta32k | false | 0 | false sales | saletime | timestamp without time zone | lzo | false | 0 | false salesmonth | salesid | integer | lzo | false | 0 | true salesmonth | listid | integer | none | true | 1 | true salesmonth | sellerid | integer | none | false | 2 | true salesmonth | buyerid | integer | lzo | false | 0 | true salesmonth | eventid | integer | mostly16 | false | 0 | true salesmonth | dateid | smallint | lzo | false | 0 | true salesmonth | qtysold | smallint | mostly8 | false | 0 | true salesmonth | pricepaid | numeric(8,2) | delta32k | false | 0 | false salesmonth | commission | numeric(8,2) | delta32k | false | 0 | false salesmonth | saletime | timestamp without time zone | lzo | false | 0 | false ``` Em seguida, verifique o tamanho de cada tabela. ``` select count(*) from sales_monthly; count ------- 2000 (1 row) select count(*) from sales; count ------- 412,214 (1 row) ``` Agora execute o comando ALTER TABLE APPEND. ``` alter table sales append from sales_monthly; ``` Verifique o tamanho de cada tabela novamente. A tabela SALES\_MONTHLY agora contém 0 linha, e a tabela SALES tem 2.000 linhas a mais. ``` select count(*) from sales_monthly; count ------- 0 (1 row) select count(*) from sales; count ------- 414214 (1 row) ``` Se a tabela de origem tiver mais colunas que a tabela de destino, especifique o parâmetro IGNOREEXTRA. O exemplo a seguir usa o parâmetro IGNOREEXTRA para ignorar colunas extras na tabela SALES\_LISTING ao acrescentar dados na tabela SALES. ``` alter table sales append from sales_listing ignoreextra; ``` Se a tabela de destino tiver mais colunas que a tabela de origem, especifique o parâmetro FILLTARGET. O exemplo a seguir usa o parâmetro FILLTARGET para preencher colunas que não existem na tabela SALES\_MONTH na tabela SALES\_REPORT. ``` alter table sales_report append from sales_month filltarget; ``` O exemplo a seguir mostra como usar ALTER TABLE APPEND com uma visão materializada como origem. ``` ALTER TABLE target_tbl APPEND FROM my_streaming_materialized_view; ``` Neste exemplo, os nomes da tabela e da visão materializada são fictícios. A anexação com base em uma visão materializada funciona somente no caso em que a visão materializada está configurada para [Ingestão de streaming para uma visão materializada](materialized-view-streaming-ingestion.md). Ela move todos os registros da visão materializada de origem para uma tabela de destino com o mesmo esquema da visão materializada e deixa a visão materializada intacta. Esse comportamento é o mesmo de quando a origem dos dados é uma tabela.