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/). 

# Semântica de transação
<a name="iceberg-writes-transaction-semantics"></a>

As consultas de gravação do Redshift Iceberg comportam ACID e isolamento de snapshot. As transações de gravação têm atomicidade garantida e não produzem atualizações parciais quando uma consulta falha inesperadamente. 

Várias transações do Iceberg podem ser executadas simultaneamente e, se duas transações tentarem modificar a mesma tabela ou partição simultaneamente, a confirmação da transação falhará. Isso garante a integridade dos dados. Quando isso acontece, você deve resolver os conflitos manualmente e executar novamente as consultas com falha. O Amazon Redshift não tenta resolver automaticamente os conflitos novamente.

Uma única consulta de gravação do Iceberg é sempre tratada como uma única transação de confirmação automática. Quando uma consulta de gravação do Iceberg, como a consulta CREATE ou INSERT, é incluída em um bloco de transação explícito, nenhuma outra consulta pode ser executada no mesmo bloco de transação. A transação falhará.

Veja a seguir alguns exemplos: O primeiro exemplo demonstra que uma única consulta de instrução sempre é confirmada automaticamente após o término da consulta. Neste cenário, você está criando uma tabela de pedidos de venda:

```
CREATE TABLE sales_schema.orders (
    order_id int, 
    customer_id int, 
    order_date date, 
    total_amount decimal(10,2)
) USING ICEBERG LOCATION 's3://my-data-lake/sales/orders/';
```

Este exemplo é um bloco de transação explícito para inserir um pedido de cliente usando a notação em três partes para um bucket de tabelas do S3. A transação não é confirmada automaticamente após a consulta INSERT, mas confirma e insere os dados do pedido com o comando COMMIT:

```
BEGIN;
INSERT INTO "analytics_bucket@s3tablescatalog".sales_db.orders VALUES (12345, 9876, '2024-10-30', 299.99);
COMMIT;
```

Este exemplo é um cenário explícito de reversão do bloco de transações em que você está testando a inserção de um pedido, mas decide cancelá-la. A transação não é confirmada automaticamente após a consulta INSERT, mas é revertida com o comando ROLLBACK sem inserir o pedido de teste.

```
BEGIN;
INSERT INTO sales_schema.orders VALUES (12346, 5432, '2024-10-30', 150.75);
ROLLBACK;
```

Este exemplo final demonstra como, quando você tenta executar outra instrução dentro do mesmo bloco de transação da consulta INSERT, a transação falha sem inserir os dados do pedido. Neste cenário, você está tentando inserir um pedido e consultar imediatamente a tabela: 

```
BEGIN;
INSERT INTO sales_schema.orders VALUES (12347, 7890, '2024-10-30', 425.50);
SELECT * FROM sales_schema.orders WHERE order_id = 12347;
```

A única exceção a isso é a instrução `DROP TABLE`, que sempre se comporta como uma instrução de confirmação automática e não pode ser executada em um bloco de transação explícito. O objetivo disso é manter o mesmo comportamento que `DROP TABLE` em uma tabela externa. Consulte mais informações em [DROP TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_TABLE.html).

**nota**  
Os SQLs de gravação do Iceberg não podem ser executados a partir do procedimento armazenado.