2021_10バンドル¶

DESCRIBE USER コマンド: 出力の新しい RSA_PUBLIC_KEY 列と RSA_PUBLIC_KEY_2 列¶

DESCRIBE USER コマンドの出力には、次の2つの新しい列が含まれます。

• RSA_PUBLIC_KEY

• RSA_PUBLIC_KEY_2

これらの2つの列は、ユーザーに現在設定されている公開キーの取得を容易にします。

制約: RELY 制約プロパティとビューの変更¶

RELY 制約プロパティ の動作、および制約の2つのビュー（ACCOUNT_USAGE の TABLE_CONSTRAINTS ビュー と INFORMATION_SCHEMA の TABLE_CONSTRAINTS ビュー）が次のように変更されました。

以前

新しい制約を作成した場合は、

• RELY がデフォルトでした。

• コマンドで NORELY を指定した場合は、これを 上書きすることは不可能 でした。コマンドで NORELY を指定した場合、 NORELY は無視されるか、エラーがスローされました。

既存の制約の場合は、 RELY 制約プロパティを変更できませんでした。

次のビューは、 RELY 制約プロパティに関する情報を提供 しません でした。

• ACCOUNT_USAGE の TABLE_CONSTRAINTS。

• INFORMATION_SCHEMA の TABLE_CONSTRAINTS。

現在

新しい制約を作成する場合は、

• NORELY がデフォルトです。

• コマンドで RELY を指定することにより、これを 上書き できます。

既存の制約には NORELY プロパティがあります（制約が現在 RELY または NORELY プロパティを持っているかどうかに関係なく）。制約プロパティは、 NORELY から RELY に 変更できます。

次のビューは、 RELY 制約プロパティが設定されているかどうかを指定する RELY 列を 含みます。

• INFORMATION_SCHEMA の TABLE_CONSTRAINTS。（更新: RELY 列は2022年8月に追加されました。）

RELY 列は、今後のリリースで ACCOUNT_USAGE の TABLE_CONSTRAINTS に追加されます。

この変更は、クエリ最適化の今後の改善をサポートするために行われました。これらの改善は、テーブルに定義された制約を利用します。

新しいデフォルトの NORELY 設定では、クエリオプティマイザーはテーブル内のデータが制約に準拠しているとは想定していません。テーブル内のデータが制約に準拠していることを確認した場合は、これを RELY に変更できます。（つまり、クエリオプティマイザーは、テーブル内のデータが制約に準拠することを期待する必要があることを示します）。

マテリアライズドビュー: データベースのクローン時にビューを作成する方法を変更¶

データベースのクローンを作成するときにマテリアライズドビューが作成される方法が、次のように変更されました。

以前

データベースのクローンを作成すると、元のデータベースでビューを作成するときに完全修飾名を指定しなかった場合でも、クローンされたデータベース内のマテリアライズドビューは完全修飾名で作成されました。

たとえば、データベース db1 に非修飾名 mv のマテリアライズドビューを作成したとします。

use database db1;
create materialized view mv as ...;

Copy

次に、データベース db1 のクローンを作成するとします。

create database db1_clone clone db1;

Copy

クローンされたデータベースにビューを作成した CREATE MATERIALIZED VIEW ステートメントは、ビューの完全修飾名を使用しました。

SHOW MATERIALIZED VIEWS コマンドを実行すると、このステートメントを表示できます。

use database db1_clone;
show materialized views;

Copy

textという名前が付けられた列には、このマテリアライズドビューを作成したコマンドのテキストが含まれます。

| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...

Copy

この例で示されているように、コマンドはマテリアライズドビュー（DB1_CLONE.PUBLIC.MV）に完全修飾名を使用しました。

現在

クローンされたデータベースの CREATE MATERIALIZED VIEW ステートメントには、これらの名前が元の CREATE MATERIALIZED VIEW ステートメントで指定されている場合を 除き、クローンされたデータベースの名前とスキーマが 含まれていません。

たとえば、データベース db1 に非修飾名 mv のマテリアライズドビューを作成するとします。

use database db1;
create materialized view mv as ...;

Copy

次に、データベース db1 のクローンを作成するとします。

create database db1_clone clone db1;

Copy

コマンドを実行すると、

use database db1_clone;
show materialized views;

-- OR --

use database db1_clone;
show views;

Copy

テキスト列の CREATE MATERIALIZED VIEW ステートメントは、元の CREATE MATERIALIZED VIEW ステートメントで非修飾名が使用されていたため、ビューに非修飾名を使用します。

| text
+------ ...
| create or replace materialized view mv as ...

Copy

この変更は、クローンされたデータベースの名前を変更する際の潜在的な問題を防ぐために行われました。クローンされたデータベースの名前を変更しても、クローンされたデータベースの元の名前はマテリアライズドビューで更新されません。

たとえば、クローンされたデータベースの名前を db1_clone から db2 に変更するとします。

alter database db1_clone rename to db2;

次のコマンドを実行すると、

use database db2;
show materialized views;

テキスト列のコマンドは、クローンされたデータベースの新しい名前（db2）ではなく、クローンされたデータベースの元の名前（db1_clone）を使用しました。

| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...

その結果、マテリアライズドビューをクエリすると、エラーが発生します。

select * from mv;

SQL compilation error: Failure during expansion of view 'MV': Cannot perform SELECT.

この動作の変更により、このエラーの発生が防止されます。

SHOW ORGANIZATIONACCOUNTS コマンド: 出力の新しい列¶

組織内にある請求エンティティへのアカウントのマッピングをより良く理解するために、 SHOW ORGANIZATION ACCOUNTS コマンドの出力に次の列が追加されました。

GET_DDL 関数: 出力の変更¶

GET_DDL 関数は、指定されたオブジェクトを再作成するために使用できる DDL ステートメントを返します。関数の引数で指定されたオブジェクトに応じて、クエリ出力が変化します。ビューに対する GET_DDL 関数の動作は次のように変更されました。

以前

Snowflakeは、ビューを再作成するために正確な SQL ステートメントを返しました。ビューがセキュアビューである場合、Snowflakeはビューを作成するための DDL ステートメントと、ビューに SECURE プロパティを設定するための ALTER ステートメントを返しました。

現在

Snowflakeは、ビューのクエリ結果を次のように更新しました。

• ビューの作成に使用された元の SQL ステートメントの文字種が大文字の場合や、大文字と小文字が混在している場合でも、クエリ結果は create or replace view の小文字の SQL テキストを返します。

• OR REPLACE 句は、常に CREATE VIEW ステートメントに含まれます。

• ビュー本文（AS）の前の SQL コメントは削除されます。

• 列リストは常に生成されます。列にマスキングポリシーが設定されている場合、結果はその列のマスキングポリシーを指定します。

• ビューの1つ以上の列または行アクセスポリシーにマスキングポリシーがあり、 GET_DDL クエリを実行するロールに APPLY MASKING POLICY またはAPPLY ROW ACCESS POLICY グローバル権限がない場合、ポリシー名は #unknown_policy に置き換えられます。以下の注意をご参照ください。

• ビューがセキュアである場合、クエリ結果には CREATE ステートメントの SECURE プロパティが含まれます。SECURE プロパティを設定するための追加の ALTER ステートメントは、クエリ結果に含まれなくなりました。

• 元の CREATE VIEW ステートメントで指定されていても、 COPY GRANTS は含まれていません。

• CREATE VIEW ステートメントの最後に常にセミコロンが含まれるようにします。

INFER_SCHEMA 関数: NULL 列に変更¶

INFER_SCHEMA 関数は、半構造化データを含んでいるステージングされたデータファイルのセットで列定義を検出し、Snowflakeオブジェクトの作成に適した形式でメタデータを取得します。

関数が列の NULL または NOT NULL 制約を返すかどうかを決定する条件は、次のように変更されました。

以前

INFER_SCHEMA 関数は、列を含むファイルのメタデータに示されているように、列のnull値の許容制約を返しました。関数の入力が単一のファイルである場合、列に対して返されるnull値の許容制約は常に正しいものでした。ただし、列が必要に応じてメタデータで識別されたが、すべての入力ファイルに含まれていなかった場合でも、関数は列に対して NOT NULL 制約を返しました。このロジックにより、 INFER_SCHEMA 関数の出力を使用して作成されたテーブルにすべてのファイルをロードすると、エラーが発生する可能性があります。

ステージングされたデータファイルのセットから派生した列定義を使用してテーブルを作成する場合（CREATE TABLE ... USING TEMPLATE 構文を使用）、テーブル内のすべての列がnull許容として定義されました。

現在

INFER_SCHEMA 関数は、列が欠落しているか、入力ファイルからオプションとして示されている場合、列をnull許容として返します。この関数は、すべての入力ファイルで列が必須であると識別された場合にのみ、列をnull非許容として返します。

GENERATE_COLUMN_DESCRIPTION 関数と CREATE TABLE ... USING TEMPLATE コマンドの構文は、 INFER_SCHEMA 関数と同じnull許容の動作に従います。

ACCESS_HISTORY ビュー: 書き込み操作のサポート¶

ACCOUNT_USAGE スキーマの ACCESS_HISTORY ビュー の動作が次のように変更されました。

以前

ACCESS_HISTORY ビューは、 SQL 読み取り操作のみをサポートしていました。

現在

ACCESS_HISTORY ビューは、次のように SQL 読み取りおよび書き込み操作をサポートします。

• ビューのクエリ出力には、書き込み操作が発生したことを示す追加の行が含まれています。

• ARRAY データ型の新しい列 OBJECTS_MODIFIED は、 SQL クエリの書き込み部分で変更されたオブジェクトを指定します。

• ステージにアクセスした場合、 objectDomain フィールドは値 STAGE を指定します。

• クエリの読み取り部分でステージにアクセスした場合は、 DIRECT_OBJECTS_ACCESSED 列と BASE_OBJECTS_ACCESSED 列が次のように更新されました。

  • 新しい JSON フィールド stageKind は、ステージを指定します。

  • objectName フィールドと objectId フィールドは、ユーザー、テーブル、および名前付きステージに対応する値を指定します。

• サポートされている書き込み操作とサポートされていない書き込み操作の詳細については、以下の 注意 をご参照ください。

次の点に注意してください。

• OBJECTS_MODIFIED 列は、次の形式で配列を返します。

  {
    "columns": [
       {
         "columnName": <string>,
         "columnId": <number>
       },
       {
         "columnName": <string>,
         "columnId": <number>
       }
      ...
    ],
    "objectId": <number>,
    "objectName": <string>,
    "objectDomain": TABLE | STAGE,
    "location": <string>,
    "stageKind": Table | User | Internal Named | External Named
  }
  

  Copy

  クエリの書き込み部分でステージにアクセスした場合、

  • objectId の値は次のとおりです。

    • ユーザー （ユーザーステージ）の NAME 識別子。

    • テーブル （テーブルステージ）の TABLE_ID 番号。

    • ステージ （名前付きステージ）の STAGE_ID 番号。

  • objectName の値は次のとおりです。

    • ユーザーステージ: 値は username です。

    • テーブルステージ: 値は table_name です。

    • 名前付きステージ: 値は stage_name です。

• クエリの書き込み部分でステージにアクセスした場合、 BASE_OBJECTS_ACCESSED 列と DIRECT_OBJECTS_ACCESSED 列には次の JSON フィールドが含まれます。

  {
    "objectDomain": STAGE
    "objectName": <string>,
    "objectId": <number>,
    "stageKind": <string>
  }
  

  Copy

  これら2つの列のフィールド名に使用できる値は、 OBJECTS_MODIFIED 列と同じです。

• Snowflakeは、 ACCESS_HISTORY ビューで次の書き込み操作をサポートしています。

  • GET <内部ステージ>

  • PUT <内部ステージ>

  • DELETE

  • INSERT

    • INSERT INTO ... FROM SELECT *

    • INSERT INTO TABLE ... VALUES ()

  • MERGE INTO ... FROM SELECT *

  • UPDATE

    • UPDATE TABLE ... FROM SELECT * FROM ...

    • UPDATE TABLE ... WHERE ...

  • データのロードステートメント:

    • COPY INTO TABLE FROM internalStage

    • COPY INTO TABLE FROM externalStage

    • COPY INTO TABLE FROM externalLocation

  • データのアンロードステートメント:

    • COPY INTO internalStage FROM TABLE

    • COPY INTO externalStage FROM TABLE

    • COPY INTO externalLocation FROM TABLE

  • CREATE:

    • CREATE DATABASE ... CLONE

    • CREATE SCHEMA ... CLONE

    • CREATE TABLE ... CLONE

    • CREATE TABLE ... AS SELECT

• Snowflakeは、 ACCESS_HISTORY ビューでの次の書き込み操作をサポートしていません。

  • ビュー、マテリアライズドビュー、およびストリームに読み込むための操作。

  • 複製に起因するデータの移動。

COPY_HISTORY: 出力内での一貫した STATUS 列の文字種¶

データロードのステータスは、Information Schemaの COPY_HISTORY テーブル関数および ACCOUNT_USAGE の COPY_HISTORY ビュー の出力にある STATUS 列で報告されます。STATUS 列に返される値は次のように変更されました。

以前

バルクデータロード（COPY INTO <テーブル> ステートメント）の場合、ステータス値は、文書化されているように、最初の単語における最初の文字を大文字で、残りの単語をすべて小文字で返しました（例: Loaded、 Load failed など）。

Snowpipeデータのロードの場合、ステータス値は大文字で返されました（例: LOADED、 LOAD FAILED など）。

現在

バルクデータロードとSnowpipeデータロードの両方で、ステータス値が返され、最初の単語における最初の文字が大文字で、残りの単語がすべて小文字で返されます。

この変更により、 STATUS 列の値に一貫性が適用され、製品ドキュメントとの整合性が保たれます。

Java UDFs: Scala JAR ファイル包含基準の変更¶

Java UDF の動作は次のように変更されました。

以前

Java UDFs の場合、Scala JAR ファイルは JVM クラスパスに含まれていました。

現在

Java UDFs の場合、Scalaライブラリはクラスパスに含まれなくなりました。Java UDF コードのいずれかがScalaライブラリに依存している場合は、新しい UDFs を作成するとき、または既存の UDFs を置き換えるときに、インポートリストにScala JAR ファイルを含めます。例:

create or replace function add(x integer, y integer)
returns integer
language java
imports = ('@stage/scala-library-2.12.jar')
handler='TestAddFunc.add'

Copy

Snowpark Scalaライブラリを使用して作成された UDFs は影響を受けません。

COPY INTO <テーブル> コマンド: MATCH_BY_COLUMN_NAME コピーオプションが CSV データのロード時にエラーを返す¶

MATCH_BY_COLUMN_NAME コピーオプションを使用すると、ソースデータで表される対応列と一致する、ターゲットテーブルの個別の列に半構造化データをロードできます。コピーオプションは、コンマ区切り値（CSV）ファイルからのデータのロードをサポートしていません。

MATCH_BY_COLUMN_NAME コピーオプションを CASE_SENSITIVE または CASE_INSENSITIVE に設定して、 CSV 形式のデータをロードするときの動作が次のように変更されました。

以前

COPY INTO <テーブル> ステートメントを CSV ファイル形式で使用してもエラーは返されませんでしたが、 MATCH_BY_COLUMN_NAME 設定はデータのロードに影響を与えなかったため、無視されます。

現在

オプションは CSV ファイルをサポートしていないため、 COPY INTO <テーブル> ステートメントはユーザーエラーを返します。

COPY INTO <場所> コマンド: Parquetデータへのアンロード時に明示的な列キャストが無視される¶

数値テーブルデータをParquetファイルにアンロードする場合は、 COPY INTO <場所> ステートメントで CAST 関数を呼び出すと、Parquetデータ型にマップするSnowflakeデータ型を選択できます。

数値列データをParquetファイルに明示的にキャストするときの動作が次のように変更されました。

以前

少なくとも1つの数値列が、Parquetデータ型にマップされていないデータ型に明示的にキャストされた場合、データアンロード操作は、Parquetデータ型にマップされた明示的なキャストを無視しました。固定小数点数の列は、 DECIMAL 列としてアンロードされました。一方、浮動小数点数の列は、 DOUBLE 列としてアンロードされました。

現在

データのアンロード操作は、ターゲットのSnowflakeデータ型がParquetデータ型にマップされているかどうかに関係なく、数値列データのすべての明示的なキャストを尊重します。

管理アカウント: 新しいアカウント名の形式をサポートするための変更¶

Snowflakeは、更新された管理アカウント名に基づいて新しい URL を導入します。これは、顧客が選択して変更できます。URL の形式は次のとおりです。

<組織名>-<管理アカウント名>.snowflakecomputing.com

新しい管理アカウント名には、2つの新しい命名規則があります。

• アンダースコア（_）は、名前の唯一の有効な区切り文字です。

• 名前は、管理アカウントが属する組織に固有である必要があります。

ほとんどの既存の管理アカウント名はすでに新しい命名規則に従っており、名前は同じままです。これらのルールに従わなかった管理アカウント名は、次のように自動的に更新されました。

• 管理アカウント名にアンダースコア以外の区切り文字が含まれている場合、それらはアンダースコアに変換されました。たとえば、管理アカウント名が managed account-1 の場合、新しい管理アカウント名は managed_account_1 です。

• 管理アカウント名が組織に固有でない場合は、ロケーター名が管理アカウント名に追加されました。たとえば、管理アカウント名が managed で、ロケーターが RE47190 の場合、新しい管理アカウント名は managed_RE47190 になります。

更新された管理アカウント名は、すべての管理アカウントコマンドで使用されます。

• CREATE MANAGED ACCOUNT は、新しい命名規則を適用します。

• SHOW MANAGED ACCOUNTS は、更新された管理アカウント名を名前列に表示します。

• DROP MANAGED ACCOUNT は、更新された管理アカウント名をパラメーターとして使用します。

SHOW SHARES コマンドおよびデータ共有 UI: 出力の変更¶

出力にアカウントロケーター（旧称: 自動生成されたアカウント名）を含む、 SHOW SHARES コマンドとデータ共有用のウェブインターフェイスが、組織名と新しいアカウント名を使用するように次のように変更されました。

以前

<アカウントロケーター>.<共有名> が表示された name 列

<アカウントロケーター> が表示された to 列（アウトバウンド共有の場合）

現在

name 列には、 <組織名>.<アカウント名>.<共有名> が表示されます。

to 列（アウトバウンド共有の場合）には、 <組織名>.<アカウント名> が表示されます。

さらに、パラメーターとして <アカウントロケーター>.<共有名> を使用するコマンド（DESCRIBE SHARE および CREATE DATABASE ... FROM SHARE）は、パラメーターとして <組織名>.<アカウント名>.<共有名> を使用できます。

アカウントロケーターと新しいアカウント名の違いの詳細については、 アカウント識別子 をご参照ください。

SHOW コマンドおよび SELECT ステートメント: 複数の共有が同じデータベースから生成された場合の出力の変更¶

以前

コンシューマーが、同じプロバイダーデータベースから作成されたデータ共有から複数のデータベースをマウントした場合（1つのデータベースから複数が共有する プロバイダー構成）、特定の状況では、同じ生成元のデータ共有に基づいて、それらの同じ生成元のデータ共有からのオブジェクトが予期せず、マウントされたデータベースでユーザーに表示されました。この問題は、データへの実際のアクセスに影響 しませんでした。オブジェクトは、ユーザーがそれらのオブジェクトにアクセスする権限を持っているかどうかをクエリしているデータベースに予期せず表示されただけです。

たとえば、プロバイダーが ORIGIN_DATABASE からのデータを共有するとします。ORIGIN_DATABASE には、 SCHEMA_A と SCHEMA_Z の2つのスキーマがあります。プロバイダーは、3つのテーブルを共有したいと考えています。2つのテーブル SCHEMA_A.TABLE1 と SCHEMA_A.TABLE2 は、 SCHEMA_A からです。プロバイダーは、 SCHEMA_Z.TABLE1 も共有したいと考えています。

プロバイダーは3つのデータ共有、 SCHEMA_A.TABLE1 から FIRST_DATASHARE、 SCHEMA_A.TABLE2 から SECOND_DATASHARE、そして SCHEMA_Z.TABLE1 から THIRD_DATASHARE を作成します。次に、プロバイダーは3つの共有にコンシューマーを追加します。

この例では、コンシューマーは、プロバイダーからのデータ共有に基づいて3つのデータベースをマウントしました。FIRST_DATABASE は FIRST_DATASHARE から、 SECOND_DATABASE は SECOND_DATASHARE から、 THIRD_DATABASE は THIRD_DATASHARE からそれぞれマウントされます。

この例のコンシューマーは、マウントしたデータベースが1つのプロバイダーデータベースから派生したものであることを認識している場合と、認識していない場合があります。

コンシューマーが SHOW OBJECTS （例: TABLES、 FUNCTIONS など）を使用してマウントされたデータベースを探索すると、異なる共有からデータベースがマウントされているにもかかわらず、マウントされた各データベースで同じ生成元のスキーマからの同じオブジェクトのセットが表示されます。

この例では、コンシューマーは SHOW OBJECTS IN ACCOUNT を使用した場合に、次の結果を得ました。この例では、出力の関連する列のみが含まれています。出力では、データベース名は、同じ生成元から最後にマウントされたデータベースによって上書きされます。

name	database_name	schema_name
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<その他のInformation Schemaオブジェクト>
TABLE1	THIRD_DATABASE	SCHEMA_A
TABLE2	THIRD_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<その他のInformation Schemaオブジェクト>
TABLE1	THIRD_DATABASE	SCHEMA_A
TABLE2	THIRD_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<その他のInformation Schemaオブジェクト>
TABLE1	THIRD_DATABASE	SCHEMA_Z

現在

コンシューマーがデータ共有からデータベースをマウントする場合、それらのデータ共有が同じプロバイダーデータベースからのものであっても、コンシューマーはプロバイダーが各データ共有に必要とする期待されるオブジェクトのみを表示します。

この例のコンシューマーには、 SHOW OBJECTS IN ACCOUNT を使用した後に次の結果が表示されます。この例では、出力の有効な列のみが含まれています。

name	database_name	schema_name
APPLICABLE_ROLES	FIRST_DATABASE	INFORMATION_SCHEMA
<その他のInformation Schemaオブジェクト>
TABLE1	FIRST_DATABASE	SCHEMA_A
APPLICABLE_ROLES	SECOND_DATABASE	INFORMATION_SCHEMA
<その他のInformation Schemaオブジェクト>
TABLE2	SECOND_DATABASE	SCHEMA_A
APPLICABLE_ROLES	THIRD_DATABASE	INFORMATION_SCHEMA
<その他のInformation Schemaオブジェクト>
TABLE1	THIRD_DATABASE	SCHEMA_Z