Pacote 2022_04¶
Este tópico descreve as seguintes mudanças de comportamento (se houver) do mês:
Recursos que foram descontinuados.
Pacote de mudanças que foram ativadas.
Outras mudanças não inclusas no pacote que foram implementadas.
Se tiver alguma dúvida sobre estas mudanças, entre em contato com o suporte Snowflake.
Para obter mais detalhes sobre os novos recursos, melhorias e correções introduzidos neste mês, consulte Julho de 2022.
Importante
Salvo indicação em contrário, estas mudanças estão no pacote 2022_04, que foi habilitado por padrão na versão 6.25.
Neste tópico:
Mudanças de SQL — Geral¶
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.
Mudanças de SQL — Comandos e funções¶
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:
Nome da coluna |
Descrição |
---|---|
|
Se Query Acceleration Service estiver habilitado para o warehouse. |
|
Fator de escala máximo de Query Acceleration Service. |
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" ... | +-------------------------------------------------------+
- 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 ... | +-------------------------------------------------------+
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" ... | +-------------------------------------------------------+
Mudanças de SQL — Exibições de uso e exibições Information Schema/funções de tabela¶
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:
Nome da coluna |
Tipo de dados |
Descrição |
---|---|---|
|
NUMBER |
Número de bytes digitalizados por Query Acceleration Service. O valor padrão é 0 se a consulta não foi acelerada. |
|
NUMBER |
Número de partições digitalizadas por Query Acceleration Service. O valor padrão é 0 se a consulta não foi acelerada. |
|
NUMBER |
Fator de escala no limite superior do qual uma consulta teria se beneficiado. O valor padrão é 0 se a consulta não foi acelerada. |
Para ajudar a limitar o impacto desta mudança, as novas colunas foram adicionadas como as últimas colunas na saída.
Mudanças no pipeline de dados¶
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:
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.
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).
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.
Mudanças na privacidade de dados¶
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.