2021_10バンドル¶
このトピックでは、その月における次の動作の変更(ある場合)について説明します。
廃止された機能。
有効になったバンドルされた変更。
その他、実装されたバンドルされていない変更。
これらの変更について質問がある場合は、 Snowflakeサポート にお問い合わせください。
今月導入された新機能、拡張機能、および修正の詳細については、 2022年2月 をご参照ください。
重要
特に明記されていない限り、これらは2021_10バンドルで変更されており、6.2リリースにおいてデフォルトで有効になっています。
このトピックの内容:
セキュリティの変更¶
DESCRIBE USER コマンド: 出力の新しい RSA_PUBLIC_KEY 列と RSA_PUBLIC_KEY_2 列¶
DESCRIBE USER コマンドの出力には、次の2つの新しい列が含まれます。
RSA_PUBLIC_KEY
RSA_PUBLIC_KEY_2
これらの2つの列は、ユーザーに現在設定されている公開キーの取得を容易にします。
SQL 変更点 --- 一般¶
制約: 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 ...;
次に、データベース
db1
のクローンを作成するとします。create database db1_clone clone db1;
クローンされたデータベースにビューを作成した CREATE MATERIALIZED VIEW ステートメントは、ビューの完全修飾名を使用しました。
SHOW MATERIALIZED VIEWS コマンドを実行すると、このステートメントを表示できます。
use database db1_clone; show materialized views;
textという名前が付けられた列には、このマテリアライズドビューを作成したコマンドのテキストが含まれます。
| text +------ ... | create or replace materialized view DB1_CLONE.PUBLIC.MV as ...
この例で示されているように、コマンドはマテリアライズドビュー(DB1_CLONE.PUBLIC.MV
)に完全修飾名を使用しました。
- 現在
クローンされたデータベースの CREATE MATERIALIZED VIEW ステートメントには、これらの名前が元の CREATE MATERIALIZED VIEW ステートメントで指定されている場合を 除き、クローンされたデータベースの名前とスキーマが 含まれていません。
たとえば、データベース
db1
に非修飾名mv
のマテリアライズドビューを作成するとします。use database db1; create materialized view mv as ...;
次に、データベース
db1
のクローンを作成するとします。create database db1_clone clone db1;
コマンドを実行すると、
use database db1_clone; show materialized views; -- OR -- use database db1_clone; show views;
テキスト列の CREATE MATERIALIZED VIEW ステートメントは、元の CREATE MATERIALIZED VIEW ステートメントで非修飾名が使用されていたため、ビューに非修飾名を使用します。
| text +------ ... | create or replace materialized view mv as ...
この変更は、クローンされたデータベースの名前を変更する際の潜在的な問題を防ぐために行われました。クローンされたデータベースの名前を変更しても、クローンされたデータベースの元の名前はマテリアライズドビューで更新されません。
たとえば、クローンされたデータベースの名前を 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.
この動作の変更により、このエラーの発生が防止されます。
SQL の変更 --- コマンドおよび関数¶
SHOW ORGANIZATIONACCOUNTS コマンド: 出力の新しい列¶
組織内にある請求エンティティへのアカウントのマッピングをより良く理解するために、 SHOW ORGANIZATION ACCOUNTS コマンドの出力に次の列が追加されました。
列名 |
データ型 |
説明 |
---|---|---|
CONSUMPTION_BILLING_ENTITY_NAME |
TEXT |
消費請求エンティティの名前。 |
MARKETPLACE_CONSUMER_BILLING_ENTITY_NAME |
TEXT |
マーケットプレイスのコンシューマー請求エンティティの名前。 |
MARKETPLACE_PROVIDER_BILLING_ENTITY_NAME |
TEXT |
マーケットプレイスプロバイダーの請求エンティティの名前。 |
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 ステートメントの最後に常にセミコロンが含まれるようにします。
注釈
マスキングポリシー、行アクセスポリシー、またはその両方を含むビューの場合は、ビューを再作成する前に
#unknown_policy
テキストを削除しないと、このテキストを含む保留中のクエリ結果のために CREATE VIEW ステートメントが失敗します。この動作は予想されます。このテキストを使用する目的は、列またはビューがポリシーによって保護されていることを示すことです。GET_DDL クエリ結果に
#unknown_policy
テキストが含まれている場合は、ビューを再作成する前に、内部ガバナンス管理者に相談して、列またはビューに必要なポリシーを決定し、 GET_DDL クエリ結果を編集してからビューを再作成します。
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許容の動作に従います。
SQL の変更 --- 使用状況ビューおよびInformation Schema¶
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 }
クエリの書き込み部分でステージにアクセスした場合、
クエリの書き込み部分でステージにアクセスした場合、 BASE_OBJECTS_ACCESSED 列と DIRECT_OBJECTS_ACCESSED 列には次の JSON フィールドが含まれます。
{ "objectDomain": STAGE "objectName": <string>, "objectId": <number>, "stageKind": <string> }
これら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'
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データ型にマップされているかどうかに関係なく、数値列データのすべての明示的なキャストを尊重します。
Data Sharingの変更¶
管理アカウント: 新しいアカウント名の形式をサポートするための変更¶
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 MANAGED ACCOUNTS コマンド: 出力の新しいアカウント名フィールド¶
SHOW MANAGED ACCOUNTS コマンドの出力は、次のように変更されました。
- 以前
URL列には、アカウントロケーター URL が次の形式で表示されていました。
<アカウントロケーター>.snowflakecomputing.com
- 現在
URL列には、組織の機能で導入された新しい URL 形式でアカウント名 URL が表示されます。新しい URL 形式は次のとおりです。
<組織名>-<管理アカウント名>.snowflakecomputing.com
さらに、出力には、アカウントロケーター URL を表示するための新しい列 account_locator_url
が含まれています。
注釈
アカウントがホストされているリージョンとクラウドプラットフォームによっては、アカウントロケーター URL に次のような追加のセグメントがある場合があります。
<アカウントロケーター>.<リージョンコード>.<クラウド>.snowflakecomputing.com
新しい URL に加えて、既存のアカウントロケーター URL は引き続き機能します。