SQLデータのタイプ: 最大長、出力、エラーメッセージに対する変更¶

注意

この動作変更は2024_08バンドルにあります。

バンドルの現在のステータスについては、バンドル履歴をご参照ください。

この動作変更により、コンパイルされた SQL 式といくつかのエラーメッセージは以下のように動作するようになります。

変更前:

コンパイルされた SQL 式とエラーメッセージで、Snowflakeはデータ型の長さを明示的に指定しました（例: VARCHAR(16777216)）。
16 MB よりも大きいオブジェクトをロードする場合、大きな文字列やファイルの解析または処理に関連するエラーが返されます（例: 100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes）。

変更後:

コンパイルされた SQL 式とエラーメッセージで、Snowflakeはデータ型の長さを省略します（例: VARCHAR）。
16 MB よりも大きいオブジェクトをロードする場合、大きなオブジェクトの保存に関連するエラーが返されます（例:100082 (22000):Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>）。

以前は、ステージ上で16 MB （MB、 BINARY、および GEOMETRY の場合は8 GEOGRAPHY）より大きいオブジェクトをクエリしようとするとエラーが発生しました。最大128 MB までのオブジェクトを読み込んで処理できるようになりました。

注釈

9.17リリースでは、16MBより大きなオブジェクトも列に格納できるようになりました。詳細については、データベースオブジェクトのサイズ制限をご参照ください。

新しいサイズ制限は、 SQL クエリ出力やメタデータでは明示的に公開されていません。ただし、より大きなサイズのオブジェクトを格納することなく作成したり読み込んだりすることで、新しく拡大された長さを暗黙的に観察することができます。この機能を有効にすると、以下のような動作の変更が導入されます。

VARCHAR と BINARY 型は、列式、 UDFs およびストアドプロシージャの GET_DDL、 SHOW、および DESCRIBE コマンドの出力に長さなしで表示されます。

たとえば、 VARCHAR(16777216) の代わりに VARCHAR が表示されます。この変更は、 DDL ステートメントで長さを明示的に指定していない新規作成オブジェクトにのみ適用されます。この変更は既存のオブジェクトには適用されません。
これまで maximum size exceeded （または類似の）エラーで失敗していたステートメントの一部は、成功するようになりました。

大きな値をロードしたり作成したりするのみで、格納したり返したりすることのないステートメントは成功するようになりました。
しかし、これまで maximum size exceeded （または類似の）エラーで失敗していたステートメントの一部は、別のエラーコードやメッセージで引き続き失敗します。

新しいエラーコードとメッセージは、依然として16 MB の制限を超えることに関連していますが、エラーは実行計画の別の部分から発生する可能性があります。たとえば、 cannot load value が cannot store value や cannot output value に変わる可能性があります。

最初の変更はすべてのお客様に影響します。2つ目と3つ目の変更は、16 MB より大きいオブジェクトをロードまたは生成しようとするお客様に影響します。

重要

16 MB よりも大きいオブジェクトに関連するエラーメッセージに依存するロジックを作成しないことを強くお勧めします。その代わりに、 BIT_LENGTH 関数を使用して値のサイズをチェックするロジックを構築することができます。

メタデータの変更¶

以下の型の操作に影響する動作の変更があります。

UDFs の返されるメタデータ
列式のあるテーブルの返されるメタデータ
SYSTEM$TYPEOF の返されるメタデータ
SHOW COLUMNS の返されるメタデータ

これらの型の操作では、結果セットのメタデータに変更があります。

注釈

このリストはすべてを網羅しているわけではありません。

UDFs の返されるメタデータ¶

入力または出力として VARCHAR または BINARY の値を使用する新しいユーザー定義関数（UDFs）の場合、 UDFs に関連する DDL ステートメントのメタデータの変更は、 GET_DDL 関数を呼び出したり、 DESCRIBE FUNCTION ステートメントを実行したり、イベントテーブルをクエリしたときに返される出力に影響します。次の例では、 UDF ファイルを作成します。

CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
  RETURNS VARCHAR
  AS $$
    'Hello' || g1
  $$;

GET_DDL¶

GET_DDL 関数の呼び出しから返されるメタデータは以下のように変更されます。

SELECT GET_DDL('function', 'udf_varchar(VARCHAR)');

変更前のメタデータ:

CREATE OR REPLACE FUNCTION "UDF_VARCHAR"("G1" VARCHAR(16777216))
RETURNS VARCHAR(16777216)
LANGUAGE SQL
AS '
  ''Hello'' || g1
';

変更後のメタデータ:

CREATE OR REPLACE FUNCTION "UDF_VARCHAR"("G1" VARCHAR)
RETURNS VARCHAR
LANGUAGE SQL
AS '
  ''Hello'' || g1
';

DESCRIBE FUNCTION¶

DESCRIBE FUNCTION ステートメントの返されるメタデータは以下のように変更されます。

DESCRIBE FUNCTION udf_varchar(VARCHAR);

変更前のメタデータ:

+-----------+-------------------+
| property  | value             |
|-----------+-------------------|
| signature | (G1 VARCHAR)      |
| returns   | VARCHAR(16777216) |
| language  | SQL               |
| body      |                   |
|           |   'Hello' || g1   |
|           |                   |
+-----------+-------------------+

変更後のメタデータ:

+-----------+-------------------+
| property  | value             |
|-----------+-------------------|
| signature | (G1 VARCHAR)      |
| returns   | VARCHAR           |
| language  | SQL               |
| body      |                   |
|           |   'Hello' || g1   |
|           |                   |
+-----------+-------------------+

イベントテーブル¶

出力として VARCHAR または BINARY の値を返す新しいユーザー定義関数の場合、イベントテーブルの RESOURCE_ATTRIBUTES 列にある snow.executable.name 属性は以下のように変更されます。

変更前のメタデータ:

{
  "db.user": "MYUSERNAME",
  "snow.database.id": 13,
  "snow.database.name": "MY_DB",
  "snow.executable.id": 197,
  "snow.executable.name": "UDF_VARCHAR(X VARCHAR):VARCHAR(16777216)",
  "snow.executable.type": "FUNCTION",
  "snow.owner.id": 2,
  "snow.owner.name": "MY_ROLE",
  "snow.query.id": "01ab0f07-0000-15c8-0000-0129000592c2",
  "snow.schema.id": 16,
  "snow.schema.name": "PUBLIC",
  "snow.session.id": 1275605667850,
  "snow.session.role.primary.id": 2,
  "snow.session.role.primary.name": "MY_ROLE",
  "snow.user.id": 25,
  "snow.warehouse.id": 5,
  "snow.warehouse.name": "MYWH",
  "telemetry.sdk.language": "python"
}

変更後のメタデータ:

{
  "db.user": "MYUSERNAME",
  "snow.database.id": 13,
  "snow.database.name": "MY_DB",
  "snow.executable.id": 197,
  "snow.executable.name": "UDF_VARCHAR(X VARCHAR):VARCHAR",
  "snow.executable.type": "FUNCTION",
  "snow.owner.id": 2,
  "snow.owner.name": "MY_ROLE",
  "snow.query.id": "01ab0f07-0000-15c8-0000-0129000592c2",
  "snow.schema.id": 16,
  "snow.schema.name": "PUBLIC",
  "snow.session.id": 1275605667850,
  "snow.session.role.primary.id": 2,
  "snow.session.role.primary.name": "MY_ROLE",
  "snow.user.id": 25,
  "snow.warehouse.id": 5,
  "snow.warehouse.name": "MYWH",
  "telemetry.sdk.language": "python"
}

列式のあるテーブルの返されるメタデータ¶

列式で VARCHAR または BINARY を使用する新しいテーブルの場合、これらの列に関連する DDL ステートメントのメタデータの変更は、 GET_DDL 関数を呼び出したときに返される出力に影響します。

以下の例では、列式のあるテーブルを作成します。

CREATE OR REPLACE TABLE table_with_default(x INT, v TEXT DEFAULT x::VARCHAR);

GET_DDL 関数の呼び出しから返されるメタデータは以下のように変更されます。

SELECT GET_DDL('table', 'table_with_default');

変更前のメタデータ:

create or replace TABLE TABLE_WITH_DEFAULT ( |
      X NUMBER(38,0),
      V VARCHAR(16777216) DEFAULT CAST(TABLE_WITH_DEFAULT.X AS VARCHAR(16777216))
);

変更後のメタデータ:

create or replace TABLE TABLE_WITH_DEFAULT ( |
      X NUMBER(38,0),
      V VARCHAR(16777216) DEFAULT CAST(TABLE_WITH_DEFAULT.X AS VARCHAR)
);

外部テーブル¶

次の例では、外部テーブルを作成します。

CREATE OR REPLACE EXTERNAL TABLE ext_table(
    data_str VARCHAR AS (value:c1::TEXT))
  LOCATION = @csv_stage
  AUTO_REFRESH = false
  FILE_FORMAT =(type = csv);

GET_DDL 関数の呼び出しから返されるメタデータは以下のように変更されます。

SELECT GET_DDL('table', 'ext_table');

変更前のメタデータ:

create or replace external table EXT_TABLE(
      DATA_STR VARCHAR(16777216) AS (CAST(GET(VALUE, 'c1') AS VARCHAR(16777216))))
location=@CSV_STAGE/
auto_refresh=false
file_format=(TYPE=csv)
;

変更後のメタデータ:

create or replace external table EXT_TABLE(
      DATA_STR VARCHAR(16777216) AS (CAST(GET(VALUE, 'c1') AS VARCHAR)))
location=@CSV_STAGE/
auto_refresh=false
file_format=(TYPE=csv)
;

SYSTEM$TYPEOF の返されるメタデータ¶

SYSTEM$TYPEOF 関数の呼び出しに対して返されるメタデータは、以下のように変更されます。

SELECT SYSTEM$TYPEOF(REPEAT('a',10));

変更前のメタデータ:

VARCHAR(16777216)[LOB]

変更後のメタデータ:

VARCHAR[LOB]

SHOW COLUMNS の返されるメタデータ¶

この変更は、既存のテーブルと新しいテーブルの両方に影響します。SHOW COLUMNS ステートメントの返されるメタデータは以下のように変更されます。

CREATE OR REPLACE TABLE t AS
  SELECT TO_VARIANT('abc') AS col;

SHOW COLUMNS IN t;

変更前のメタデータ:

{
  "type":"VARIANT",
  "length":16777216,
  "byteLength":16777216,
  "nullable":true,
  "fixed":false
}

変更後のメタデータ:

{
  "type":"VARIANT",
  "nullable":true,
  "fixed":false
}

16 MB よりも大きいオブジェクトの読み込みと処理に関する変更¶

以下の操作のタイプを使用して16 MB よりも大きいサイズのオブジェクトをロードまたは処理しようとすると、影響がでる可能性のある動作変更があります。

ステージ上のファイルのスキャンによるデータのロード
ソースファイルからの大型オブジェクト全体のクエリ
クエリ結果に大型オブジェクトを含める
集計を使用した大きなオブジェクトの作成

注釈

このリストはすべてを網羅しているわけではありません。

ステージ上のファイルのスキャンによるデータのロード¶

ステージ上のファイルをスキャンして16 MB よりも大きいデータをロードしようとすると、エラーメッセージが返されます。

CREATE TABLE AS SELECT を使用した大型オブジェクト全体のロード
COPY INTO <テーブル名> ... FROM SELECT を使用した大型オブジェクト全体のロード
COPY INTO <テーブル名> ... FROM <ステージまたはロケーション> を使用した大型オブジェクト全体のロード

CREATE TABLE AS SELECT を使用した大型オブジェクト全体のロード¶

VARCHAR、 VARIANT、 OBJECT、 ARRAY の場合は、16 MB よりも大きいオブジェクト（または BINARY、 GEOMETRY、 GEOGRAPHY の場合は8 MB よりも大きいオブジェクト）をロードするために CREATE TABLE AS SELECT ステートメントを使用しようとすると、別のエラーメッセージが表示されます。エラーはソースのタイプによって異なります。このシナリオで INSERT INTO SELECT ステートメントを使用する場合は、同一のメッセージ変更が適用されます。

JSON ソースからの大型オブジェクト全体のロード
XML ソースからの大型オブジェクト全体のロード

JSON ソースからの大型オブジェクト全体のロード¶

以下の例では、 CREATE TABLE AS SELECT を使用して、 JSON ソースから16 MB よりも大きいオブジェクト全体をロードしようとしています。

CREATE OR REPLACE FILE FORMAT json_format TYPE = JSON;

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR) AS
  SELECT $1::VARCHAR
    FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format');

変更前のエラーメッセージ:

100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

XML ソースからの大型オブジェクト全体のロード¶

以下の例では、 CREATE TABLE AS SELECT を使用して、 XML ソースから16 MB よりも大きいオブジェクト全体をロードしようとしています。

CREATE or REPLACE FILE FORMAT xml_format TYPE = XML;

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR) AS
  SELECT $1 AS XML
    FROM @lob_int_stage/large_xml.xte (FILE_FORMAT => 'xml_format');

変更前のエラーメッセージ:

100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100078 (22000): String '<string_preview>' is too long and would be truncated

COPY INTO <テーブル名> ... FROM SELECT を使用した大型オブジェクト全体のロード¶

VARCHAR、 VARIANT、 OBJECT、 ARRAY の場合は、16 MB よりも大きいオブジェクト（または BINARY、 GEOMETRY、 GEOGRAPHY の場合は8 MB よりも大きいオブジェクト）をロードするために COPY INTO <テーブル名> ... FROM SELECT ステートメントを使用しようとすると、別のエラーメッセージが表示されます。エラーはソースのタイプによって異なります。

JSON ソースからの大型オブジェクト全体のロード
JSON ソースからのネストされた大型オブジェクトのロード
XML ソースからの大型オブジェクト全体のロード

重要

ON_ERROR=CONTINUE のある COPY INTO コマンドを使用して16 MB より大きいオブジェクトを含むデータをロードしようとし、エラーログに書かれたエラーメッセージに依存している場合は、エラーメッセージの変更により、エラーメッセージに依存するロジックに問題が発生する可能性があります。

JSON ソースからの大型オブジェクト全体のロード¶

以下の例では、 COPY INTO <テーブル名> ... FROM SELECT を使用して、 JSON ソースから16 MB よりも大きいオブジェクト全体をロードしようとしています。

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar FROM (
  SELECT $1::VARCHAR
    FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format'));

変更前のエラーメッセージ:

100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

JSON ソースからのネストされた大型オブジェクトのロード¶

次の例では、ネストされた大型オブジェクトにアクセスするときに、 JSON データをロードしようとします。

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar FROM (
  SELECT $1:"Driver_Status"
    FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format'));

変更前のエラーメッセージ:

100069 (22P02): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>

変更後のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

XML ソースからの大型オブジェクト全体のロード¶

以下の例では、 COPY INTO <テーブル名> ... FROM SELECT を使用して、 XML ソースから16 MB よりも大きいオブジェクト全体をロードしようとしています。

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar FROM (
  SELECT $1::VARCHAR AS lob_column
    FROM @lob_int_stage/large_xml.xte (FILE_FORMAT => 'xml_format'));

変更前のエラーメッセージ:

100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>

COPY INTO <テーブル名> ... FROM <ステージまたはロケーション> を使用した大型オブジェクト全体のロード¶

VARCHAR、 VARIANT、 OBJECT、 ARRAY の場合は、16 MB よりも大きいオブジェクト（または BINARY、 GEOMETRY、 GEOGRAPHY の場合は8 MB よりも大きいオブジェクト）をロードするために COPY INTO <テーブル名> ... FROM <ステージまたはロケーション> ステートメントを使用しようとすると、別のエラーメッセージが表示されます。エラーはソースのタイプによって異なります。

大きなオブジェクトで COPY コマンドを使用した場合、 ON_ERROR パラメーターを CONTINUE に設定しても、クエリに失敗することがあります。詳細については、 COPY コマンドの使用上の注意をご参照ください。

JSON ソースからの大型オブジェクト全体のロード
XML ソースからの大型オブジェクト全体のロード

重要

ON_ERROR=CONTINUE のある COPY INTO コマンドを使用して16 MB より大きいオブジェクトを含むデータをロードしようとし、エラーログに書かれたエラーメッセージに依存している場合は、エラーメッセージの変更により、メッセージに依存するロジックに問題が発生する可能性があります。

JSON ソースからの大型オブジェクト全体のロード¶

以下の例では、 COPY INTO <テーブル名> ... FROM <ステージまたはロケーション> を使用して、 JSON ソースから16 MB よりも大きいオブジェクト全体をロードしようとしています。

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar (lob_column)
  FROM @lob_int_stage/driver_status.json.gz
  FILE_FORMAT = (FORMAT_NAME = json_format);

変更前のエラーメッセージ:

100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

XML ソースからの大型オブジェクト全体のロード¶

以下の例では、 COPY INTO <テーブル名> ... FROM <ステージまたはロケーション> を使用して、 XML ソースから16 MB よりも大きいオブジェクト全体をロードしようとしています。

CREATE OR REPLACE TABLE table_varchar (lob_column VARCHAR);

COPY INTO table_varchar (lob_column)
  FROM @lob_int_stage/large_xml.xte
  FILE_FORMAT = (FORMAT_NAME = xml_format);

変更前のエラーメッセージ:

100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

ソースファイルからの大型オブジェクト全体のクエリ¶

現在、16 MB よりも大きいオブジェクトは結果セットに含めることができないため、 VARCHAR、 VARIANT、 OBJECT、 ARRAY の場合は16 MB よりも大きい（または、 BINARY、 GEOMETRY、 GEOGRAPHY の場合は8 MB よりも大きい）オブジェクトをソースファイルからクエリしようとすると、別のエラーメッセージが表示されます。エラーはソースのタイプによって異なります。

JSON ソースからの大型オブジェクト全体のクエリ
XML ソースからの大型オブジェクト全体のクエリ
CSV ソースからの大型オブジェクト全体のクエリ
Parquetソースからの大型オブジェクト全体のクエリ

JSON ソースからの大型オブジェクト全体のクエリ¶

以下の例では、 JSON ソースから16 MB よりも大きいオブジェクト全体をクエリしようとしています。

SELECT $1
  FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format');

変更前のエラーメッセージ:

100069 (22P02): Error parsing JSON: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

XML ソースからの大型オブジェクト全体のクエリ¶

以下の例では、 XML ソースから16 MB よりも大きいオブジェクト全体をクエリしようとしています。

SELECT $1 as lob_column
  FROM @lob_int_stage/large_xml.xte (FILE_FORMAT => 'xml_format');

変更前のエラーメッセージ:

100100 (22P02): Error parsing XML: document is too large, max size 16777216 bytes

変更後のエラーメッセージ:

100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

CSV ソースからの大型オブジェクト全体のクエリ¶

以下の例では、 CSV ソースから16 MB よりも大きいオブジェクト全体をクエリしようとしています。

SELECT $1
  FROM @lob_int_stage/driver_status.csv.gz (FILE_FORMAT => 'csv_format');

変更前のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>

変更後のエラーメッセージ:

100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

Parquetソースからの大型オブジェクト全体のクエリ¶

以下の例では、Parquetソースから16 MB よりも大きいオブジェクト全体をクエリしようとしています。

SELECT $1
  FROM @lob_int_stage/driver_status.parquet (FILE_FORMAT => 'parquet_format');

変更前のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <object_size>

変更後のエラーメッセージ:

100082 (22000): The data length in result column $1 is not supported by this version of the client. Actual length <actual_length> exceeds supported length of 16777216.

クエリ結果に大型オブジェクトを含める¶

メモリ内で16 MB より大きなオブジェクトを作成できるようになりました。しかし、これらのオブジェクトをクエリ結果に含めたり、テーブルに格納したりすることはできません。これを実行しようとすると、エラーメッセージが返されます。

クエリ結果に 16 MB より大きいオブジェクトを含めようとする
テーブルに16 MB より大きなオブジェクトを格納しようとする

クエリ結果に 16 MB より大きいオブジェクトを含めようとする¶

次のクエリは、2つの大きな文字列を連結しようとします。

SELECT large_str || large_str FROM lob_strings;

変更前のエラーメッセージ:

100078 (22000): String '<preview_of_string>' is too long and would be truncated in 'CONCAT'

変更後のエラーメッセージ:

100067 (54000): The data length in result column <column_name> is not supported by this version of the client. Actual length <actual_size> exceeds supported length of 16777216.

テーブルに16 MB より大きなオブジェクトを格納しようとする¶

次の CREATE TABLE AS SELECT ステートメントは、2つの大きな文字列を連結しようとします。

CREATE OR REPLACE TABLE table_varchar
  AS SELECT large_str || large_str as LOB_column
  FROM lob_strings;

変更前のエラーメッセージ:

100078 (22000): String '<preview_of_string>' is too long and would be truncated in 'CONCAT'

変更後のエラーメッセージ:

100067 (54000): The data length in result column <column_name> is not supported by this version of the client. Actual length <actual_size> exceeds supported length of 16777216.

集計を使用した大きなオブジェクトの作成¶

16 MB より大きなオブジェクトを作成し、その出力を返そうとすると、エラーメッセージが返されます。

以下の例では、大型オブジェクト列のクエリで ARRAY_AGG 関数を使用します。

SELECT ARRAY_AGG(status) FROM lob_object;

変更前のエラーメッセージ:

100082 (22000): Max LOB size (16777216) exceeded, actual size of parsed column is <actual_size>

変更後のエラーメッセージ:

100067 (54000): The data length in result column <column_name> is not supported by this version of the client. Actual length <actual_size> exceeds supported length of 16777216.

参照:1779