Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 90 additions & 0 deletions docs/source/format/CanonicalExtensions.rst
Original file line number Diff line number Diff line change
Expand Up @@ -546,6 +546,96 @@ Primitive Type Mappings
| UUID extension type | UUID |
+----------------------+------------------------+

.. _parquet_file_extension:

Parquet File
============

File represents a reference to a range of bytes stored inline or in an external
file. It is intended for use cases such as file inventories, manifests, and
references to unstructured data such as images or audio files in object
storage.

Field semantics, byte resolution rules, and value validation are defined by the
`Parquet FILE logical type specification <https://github.com/apache/parquet-format/blob/master/LogicalTypes.md#file>`__.
These requirements apply to this extension type.

* Extension name: ``arrow.parquet.file``.

* The storage type of this extension is a ``Struct`` containing at least one of
the following nullable fields:

.. list-table::
:header-rows: 1

* - Field
- Type
* - ``uri``
- ``String``, ``LargeString``, or ``StringView``
* - ``offset``

@rok rok Oct 27, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For FileType in Parquet offset will point to a region of a uri referenced file. However Parquet allows for the uri to be relative. How should Arrow users interpret that?

How about we specify that offset with relative uri is - unlinke in Parquet - meaningless.
We can stop there or also recommend that Parquet reader can attempt and record absolute uri, by checking for the file relative to the source parquet file's location.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Rok. I added a section clarifying relative URI resolution.

- ``Int64``
* - ``size``
- ``Int64``
* - ``content_type``
- ``String``, ``LargeString``, or ``StringView``
* - ``checksum``
- ``String``, ``LargeString``, or ``StringView``
* - ``inline``
- ``Binary``, ``LargeBinary``, or ``BinaryView``

The fields may be in any order and must be accessed by case-sensitive name,
not by position. Each field may occur at most once and may be omitted from
the ``Struct`` when it is not used. The ``Struct`` must not contain fields
other than those listed above.

* Extension type parameters:

This type does not have any parameters.

* Description of the serialization:

Extension metadata is an empty string.

Relative URI resolution
-----------------------

Unlike in Parquet, an ``offset`` paired with a relative ``uri`` is meaningless
in this extension type.

Parquet readers can attempt to resolve relative URIs by checking for the
referenced file relative to the source Parquet file's location. If successful,
they should record the absolute URI in the Arrow array's ``uri`` field.

Examples
--------

A storage type containing all defined fields is::

Struct<
uri: String,
offset: Int64,
size: Int64,
content_type: String,
checksum: String,
inline: Binary
>

All six child fields in this example are nullable. An inline-only storage type
may contain only the fields it uses::

Struct<
inline: Binary,
content_type: String
>

Similarly, a whole-file external reference may use::

Struct<
uri: String,
content_type: String,
checksum: String
>

.. _timestamp_with_offset_extension:

Timestamp With Offset
Expand Down
Loading