Pacote 2022_04¶

Clonagem de um esquema permanente com tabelas filho permanentes para criar um esquema transitório¶

Quando um esquema transitório é criado pela clonagem de um esquema permanente, os objetos filho no esquema também são clonados.

O tipo dos objetos de tabela filho no esquema transitório clonado mudou da seguinte forma:

Anteriormente

Todas as tabelas permanentes no esquema de origem eram clonadas como tabelas permanentes no esquema de destino, e todas as tabelas transitórias eram clonadas como tabelas transitórias.

Atualmente

Todas as tabelas permanentes no esquema de origem são clonadas como tabelas transitórias no esquema de destino.

Comando SHOW EXTERNAL TABLES: novas colunas na saída¶

As duas novas colunas seguintes foram adicionadas à saída do comando SHOW EXTERNAL TABLES:

• TABLE_FORMAT

• LAST_REFRESH_DETAILS

Para ajudar a limitar o impacto dessa mudança, as colunas foram adicionadas como as últimas colunas na saída.

As colunas foram adicionadas para oferecer suporte a funcionalidades futuras.

Comando SHOW SCHEMAS: modificações da saída de RETENTION_TIME para esquemas¶

O valor da coluna RETENTION_TIME na saída do comando SHOW SCHEMAS para esquemas em um banco de dados com uma configuração DATA_RETENTION_TIME_IN_DAYS de 0 mudou da seguinte forma:

Anteriormente

O valor RETENTION_TIME era uma cadeia de caracteres vazia.

Atualmente

O valor RETENTION_TIME é 0.

Comando SHOW WAREHOUSES: novas colunas na saída¶

As seguintes novas colunas foram adicionadas à saída do comando SHOW WAREHOUSES para contas que tenham o recurso Query Acceleration Service habilitado:

As novas colunas foram adicionadas entre as colunas comment e resource_monitors. Consultas que dependem da saída do comando SHOW WAREHOUSES devem usar o nome da coluna em vez de um índice embutido em código da saída da coluna.

Função GET_DDL: mudanças na saída de funções e procedimentos¶

Atualmente, quando você chama a função GET_DDL para obter a instrução DDL que criou uma UDF, uma função externa ou um procedimento armazenado, o nome da função ou procedimento é delimitado entre aspas duplas, mesmo que o nome siga as regras para identificadores de objetos não delimitado entre aspas.

Essa saída mudou nos casos em que você retorna o nome totalmente qualificado da função ou procedimento (isto é, quando você chama GET_DDL com TRUE como terceiro argumento):

Anteriormente

GET_DDL retornava o nome da função ou procedimento entre aspas:

+-------------------------------------------------------+
| GET_DDL('FUNCTION', 'MYFUNC(FLOAT)', TRUE)            |
|-------------------------------------------------------|
| CREATE OR REPLACE FUNCTION MYDB.MYSCHEMA."MYFUNC" ... |
+-------------------------------------------------------+

Copy

Atualmente

GET_DDL retornava o nome da função ou procedimento sem aspas:

+-------------------------------------------------------+
| GET_DDL('FUNCTION', 'MYFUNC(FLOAT)', TRUE)            |
|-------------------------------------------------------|
| CREATE OR REPLACE FUNCTION MYDB.MYSCHEMA.MYFUNC ...   |
+-------------------------------------------------------+

Copy

Observe que isso só afeta os casos em que você retorna o nome totalmente qualificado da função ou procedimento. Se você omitir o terceiro argumento para GET_DDL (ou especificar FALSE), GET_DDL retorna o nome da função ou procedimento delimitado entre aspas:

+-------------------------------------------------------+
| GET_DDL('FUNCTION', 'MYFUNC(FLOAT)')                  |
|-------------------------------------------------------|
| CREATE OR REPLACE FUNCTION "MYFUNC" ...               |
+-------------------------------------------------------+

Copy

Exibição POLICY_REFERENCES (Account Usage): novas colunas¶

Para oferecer suporte às políticas de mascaramento baseadas em tag, a exibição POLICY_REFERENCES (no esquema ACCOUNT_USAGE do banco de dados compartilhado SNOWFLAKE) inclui agora as seguintes colunas:

• nome_da_tag

• banco_dos_dados_da_tag

• esquema_da_tag

• status_da_politica

Com essas novas colunas, observe que:

• As colunas, seus tipos de dados e descrições correspondem às mesmas colunas na função de tabela POLICY_REFERENCES de Information Schema.

• Para as linhas existentes na exibição, Snowflake retorna NULL para as novas colunas.

• Esta atualização só adiciona novas colunas à exibição. É possível usar o recurso de política de mascaramento baseado em tags sem permitir esta mudança de comportamento, desde que sua conta Snowflake seja Enterprise Edition (ou superior).

Para ajudar a limitar o impacto dessa mudança, essas novas colunas foram adicionadas como as últimas colunas na saída.

Exibição QUERY_HISTORY (Account Usage): novas colunas¶

As seguintes novas colunas foram adicionadas à exibição QUERY_HISTORY de Account Usage:

Para ajudar a limitar o impacto desta mudança, as novas colunas foram adicionadas como as últimas colunas na saída.

Comando ALTER STREAM: definição dos parâmetros APPEND_ONLY ou INSERT_ONLY não permitida a partir de agora¶

O tipo de fluxo não pode ser alterado depois que o fluxo é criado. O tipo é definido da seguinte forma quando o fluxo é criado:

• Defina APPEND_ONLY = TRUE para criar um fluxo apenas de anexação.

• Defina INSERT_ONLY = TRUE para criar um fluxo apenas de inserção.

• Omitir ambos os parâmetros para criar um fluxo padrão (delta).

A tentativa de alterar o tipo de um fluxo existente usando o comando ALTER STREAM agora retorna um erro do usuário.

Para alterar o tipo de um fluxo existente, é necessário recriar o fluxo (usando CREATE OR REPLACE STREAM) e especificar o tipo de fluxo desejado.

Tarefas: mudanças de mensagens de erro¶

As mensagens de erro do usuário retornadas ao tentar ações SQL inválidas relacionadas a tarefas sem servidor (isto é, tarefas executadas usando recursos de computação gerenciados por Snowflake) mudaram da seguinte forma:

• Caso de uso 1: usando uma função sem o privilégio global EXECUTE MANAGED TASK, execute uma instrução CREATE TASK e omita o parâmetro WAREHOUSE.

  Texto do erro anterior

  Missing option(s): [WAREHOUSE]

  Texto do erro atual

  WAREHOUSE not specified and missing serverless task privilege to create task {task name}. To create it as a user-managed task, specify a WAREHOUSE. To create it as a serverless task, execute the CREATE TASK command with a role that has been granted the 'EXECUTE MANAGED TASK' account-level privilege.

• Caso de uso 2: usando uma função sem o privilégio global EXECUTE MANAGED TASK, clone uma tarefa sem servidor (ou um banco de dados ou esquema que contenha uma ou mais tarefas sem servidor) usando o comando CREATE … CLONE apropriado.

  Texto do erro anterior

  Task {task name} requires a warehouse.

  Texto do erro atual

  WAREHOUSE not specified and missing serverless task privilege to create task {task name}. To create it as a user-managed task, specify a WAREHOUSE. To create it as a serverless task, execute the CLONE command with a role that has been granted the 'EXECUTE MANAGED TASK' account-level privilege.

• Use o caso 3: usando uma função sem o privilégio global EXECUTE MANAGED TASK, remova a definição do parâmetro WAREHOUSE de uma tarefa existente que é executada usando os recursos de computação gerenciados pelo cliente (usando uma instrução ALTER TASK … UNSET WAREHOUSE).

  Texto do erro anterior

  Task {task name} requires a warehouse.

  Texto do erro anterior

  UNSET WAREHOUSE não é permitido na tarefa {nome_da_tarefa} porque sua função de proprietário não recebeu o privilégio no nível de conta 'EXECUTE MANAGED TASK'. Conceda esse privilégio à função ou use GRANT OWNERSHIP para mudar a função de proprietário da tarefa para uma com esse privilégio.

• Caso de uso 4:

  1. Usando uma função que possui o privilégio global EXECUTE MANAGED TASK (juntamente com outros privilégios mínimos), crie e retome uma tarefa sem servidor.

  2. O privilégio EXECUTE MANAGED TASK é revogado da função de proprietário (a função que tem o privilégio OWNERSHIP sobre a tarefa).

  3. A tarefa não é pausada e inicia sua próxima execução agendada, ou um usuário com a função de proprietário executa o comando EXECUTE TASK para tentar iniciar uma execução de tarefa.

  Texto do erro anterior

  Cannot execute task, USAGE privilege on the task's warehouse must be granted to the owner role

  Texto do erro atual

  Não é possível executar a tarefa, o privilégio EXECUTE MANAGED TASK deve ser concedido à função de proprietário.

Essas mudanças se destinam a ajudá-lo a compreender e resolver melhor as questões relacionadas às tarefas sem servidor.

Classificação: atualizações do modelo de classificação de dados e saída revisada¶

A classificação de dados agora está com disponibilidade geral (GA) em todas as contas Enterprise Edition (ou superior) em AWS e Azure.

Para a GA do recurso, o modelo de classificação de dados foi atualizado para gerar melhores modelos de previsão e resultados de padrões de dados. Além disso, o processo de classificação de dados agora inclui a saída de cada coluna de tabela especificada na entrada, incluindo:

• Colunas com tipos de dados que antes não podiam ser classificados.

• Colunas apenas com valores NULL.

Essas melhorias foram introduzidas através do processo de mudança de comportamento porque provavelmente retornam melhores resultados, mas potencialmente diferentes, ao reclassificar dados que foram classificados usando o modelo de classificação de dados anterior. Durante a fase de recusa do pacote 2022_04, é possível ativar/desativar o pacote para testar as melhorias de classificação, enquanto o impacto em suas contas de produção também é minimizado até que você esteja familiarizado com os novos resultados.