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 (BINARY、 GEOMETRY、および GEOGRAPHY の場合は8 MB)より大きいオブジェクトをクエリしようとするとエラーが発生しました。最大128 MB までのオブジェクトを読み込んで処理できるようになりました。サイズが16 MB 以上のオブジェクトを列にロードしたり、結果セットに出力したりすることはまだできませんが、サイズが128 MB (BINARY、 GEOMETRY、および GEOGRAPHY の場合は64 MB)までのオブジェクトをステージ上のファイルにクエリし、オブジェクトのサイズを縮小してから列に格納することができます。

詳細については、 ロード前に16 MB より大きいオブジェクトのサイズを縮小する をご参照ください。

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

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

    たとえば、 VARCHAR(16777216) の代わりに VARCHAR が表示されます。この変更は、 DDL ステートメントで長さを明示的に指定していない新規作成オブジェクトにのみ適用されます。この変更は既存のオブジェクトには適用されません。

  • これまで maximum size exceeded (または類似の)エラーで失敗していたステートメントの一部は、成功するようになりました。

    大きな値をロードしたり作成したりするのみで、格納したり返したりすることのないステートメントは成功するようになりました。

  • しかし、これまで maximum size exceeded (または類似の)エラーで失敗していたステートメントの一部は、別のエラーコードやメッセージで引き続き失敗します。

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

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

重要

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

メタデータの変更

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

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

注釈

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

UDFs の返されるメタデータ

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

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

GET_DDL

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

SELECT GET_DDL('function', 'udf_varchar(VARCHAR)');
Copy
変更前のメタデータ:
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);
Copy
変更前のメタデータ:
+-----------+-------------------+
| 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"
}
Copy
変更後のメタデータ:
{
  "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"
}
Copy

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

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

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

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

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

SELECT GET_DDL('table', 'table_with_default');
Copy
変更前のメタデータ:
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);
Copy

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

SELECT GET_DDL('table', 'ext_table');
Copy
変更前のメタデータ:
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));
Copy
変更前のメタデータ:
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;
Copy
変更前のメタデータ:
{
  "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 を使用した大型オブジェクト全体のロード

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

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');
Copy
変更前のエラーメッセージ:
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');
Copy
変更前のエラーメッセージ:
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 ステートメントを使用しようとすると、別のエラーメッセージが表示されます。エラーはソースのタイプによって異なります。

重要

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'));
Copy
変更前のエラーメッセージ:
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'));
Copy
変更前のエラーメッセージ:
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'));
Copy
変更前のエラーメッセージ:
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 コマンドの使用上の注意 をご参照ください。

重要

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);
Copy
変更前のエラーメッセージ:
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);
Copy
変更前のエラーメッセージ:
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 ソースからの大型オブジェクト全体のクエリ

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

SELECT $1
  FROM @lob_int_stage/driver_status.json.gz (FILE_FORMAT => 'json_format');
Copy
変更前のエラーメッセージ:
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');
Copy
変更前のエラーメッセージ:
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');
Copy
変更前のエラーメッセージ:
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');
Copy
変更前のエラーメッセージ:
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 より大きいオブジェクトを含めようとする

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

SELECT large_str || large_str FROM lob_strings;
Copy
変更前のエラーメッセージ:
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;
Copy
変更前のエラーメッセージ:
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;
Copy
変更前のエラーメッセージ:
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