Information Schema: COPY_HISTORY behavior changes (Pending)¶

Post-truncate load history¶

BCR-1493 introduced the truncate boundary for COPY_HISTORY, but it only took effect for COPY INTO entries. This change extends that behavior to Snowpipe entries as well.

Before the change:

The COPY_HISTORY function honors the truncate boundary only for COPY INTO entries. Snowpipe entries may continue to show load history from before the latest truncate operation on the target table.

After the change:

The COPY_HISTORY function honors the truncate boundary for both Snowpipe and COPY INTO entries. After a table is truncated, only post-truncate load history is shown.

Iceberg copy history format¶

The file paths shown in COPY_HISTORY when loading Parquet files into a Snowflake Managed Iceberg table using LOAD_MODE = ADD_FILES_COPY with COPY INTO or Snowpipe are now consistent across load methods.

Before the change:

When using LOAD_MODE = ADD_FILES_COPY, the file column in COPY_HISTORY may include additional path prefixes. For example, if the stage is s3://bucket/lightweight/test/ and the file is existing/parquet/files/file1.parquet, the COPY_HISTORY function shows lightweight/test/t1/existing/parquet/files/file1.parquet instead of the correct relative path.

After the change:

The file column in COPY_HISTORY consistently shows the correct relative file path. Using the example above, the function now shows existing/parquet/files/file1.parquet.

Pipe metadata limit per table¶

Before the change:

The COPY_HISTORY function returns metadata for all pipes associated with a table, regardless of how many pipes are configured.

After the change:

If a table has more than 1000 associated pipes, the COPY_HISTORY function returns metadata for up to 1000 pipes.

Ref: 2305