resolve comments

Author: wraymo

presto-docs/src/main/sphinx/connector/clp.rst

@@ -306,12 +306,13 @@ Each JSON log maps to this unified ``ROW`` type, with absent fields represented
 ``status``, ``thread_num``, ``backtrace``) become fields within the ``ROW``, clearly reflecting the nested and varying
 structures of the original JSON logs.
 
+*************
 CLP Functions
--------------
+*************
 
-In semi-structured logs, the number of potential keys can grow significantly, resulting in extremely wide Presto tables
-with many columns. To manage this complexity, the metadata provider may expose only a subset of the full schema,
-typically the static fields or those most relevant to expected queries.
+Semi-structured logs can have many potential keys, which can lead to very wide Presto tables. To keep table metadata
+concise and still preserve access to dynamic fields, the connector provides two sets of functions that are specific to
+the CLP connector. These functions are not part of standard Presto SQL.
 
 To enable access to dynamic or less common fields not present in the exposed schema, CLP provides two set of functions
 to help users query flexible log schemas while keeping the table metadata definition concise. These functions are only
@@ -320,33 +321,33 @@ available in the CLP connector and are not part of standard Presto SQL.
 - JSON path functions (e.g., ``CLP_GET_STRING``)
 - Wildcard column matching functions for use in filter predicates (e.g., ``CLP_WILDCARD_STRING_COLUMN``)
 
-There is **no performance penalty** for using these functions. During query optimization, they are rewritten into
-references to actual schema-backed columns or valid symbols in KQL queries. This avoids additional parsing overhead and
-delivers performance comparable to querying standard columns.
+There is **no performance penalty** when using these functions. During query optimization, the connector rewrites these
+functions to references to concrete schema-backed columns or valid symbols in KQL queries. This avoids additional
+parsing overhead and delivers performance comparable to querying standard columns.
 
 Path-Based Functions
-^^^^^^^^^^^^^^^^^^^^
+====================
 
 .. function:: CLP_GET_STRING(varchar) -> varchar
 
-    Returns the string value of the given JSON path, where the column type is one of: ``ClpString``, ``VarString``, or
+    Returns the string value at the given JSON path, where the column type is one of: ``ClpString``, ``VarString``, or
     ``DateString``. Returns a Presto ``VARCHAR``.
 
 .. function:: CLP_GET_BIGINT(varchar) -> bigint
 
-    Returns the integer value of the given JSON path, where the column type is ``Integer``, Returns a Presto ``BIGINT``.
+    Returns the integer value at the given JSON path, where the column type is ``Integer``, Returns a Presto ``BIGINT``.
 
 .. function:: CLP_GET_DOUBLE(varchar) -> double
 
-    Returns the double value of the given JSON path, where the column type is ``Float``.  Returns a Presto ``DOUBLE``.
+    Returns the double value at the given JSON path, where the column type is ``Float``.  Returns a Presto ``DOUBLE``.
 
 .. function:: CLP_GET_BOOL(varchar) -> boolean
 
-    Returns the double value of the given JSON path, where the column type is ``Boolean``. Returns a Presto ``BOOLEAN``.
+    Returns the boolean value at the given JSON path, where the column type is ``Boolean``. Returns a Presto ``BOOLEAN``.
 
 .. function:: CLP_GET_STRING_ARRAY(varchar) -> array(varchar)
 
-    Returns the array value of the given JSON path, where the column type is ``UnstructuredArray`` and converts each
+    Returns the array value at the given JSON path, where the column type is ``UnstructuredArray`` and converts each
     element into a string. Returns a Presto ``ARRAY(VARCHAR)``.
 
 .. note::
@@ -355,7 +356,8 @@ Path-Based Functions
    - Wildcards (e.g., ``msg.*.ts``) are **not supported**.
    - If a path is invalid or missing, the function returns ``NULL`` rather than raising an error.
 
-Examples:
+Examples
+--------
 
 .. code-block:: sql
 
@@ -369,33 +371,33 @@ Examples:
 
 
 Wildcard Column Functions
-^^^^^^^^^^^^^^^^^^^^^^^^^
+=========================
 
 These functions are used to apply filter predicates across all columns of a certain type. They are useful for searching
 across unknown or dynamic schemas without specifying exact column names. Similar to the path-based functions, these
 functions are rewritten during query optimization to a KQL query that matches the appropriate columns.
 
 .. function:: CLP_WILDCARD_STRING_COLUMN() -> varchar
 
-   Represents all columns of CLP types: ``ClpString``, ``VarString``, and ``DateString``.
+   Represents all columns whose CLP types are ``ClpString``, ``VarString``, or ``DateString``.
 
 .. function:: CLP_WILDCARD_INT_COLUMN() -> bigint
 
-   Represents all columns of CLP type: ``Integer``.
+   Represents all columns whose CLP type is ``Integer``.
 
 .. function:: CLP_WILDCARD_FLOAT_COLUMN() -> double
 
-   Represents all columns of CLP type: ``Float``.
+   Represents all columns whose CLP type is ``Float``.
 
 .. function:: CLP_WILDCARD_BOOL_COLUMN() -> boolean
 
-   Represents all columns of CLP type: ``Boolean``.
+   Represents all columns whose CLP type is ``Boolean``.
 
 .. note::
 
-   - They must appear **only in filter conditions** (`WHERE` clause). They cannot be selected or passed as arguments
-     to other functions.
-   - Supported operators includes:
+   - Wildcard functions must appear **only in filter conditions** (`WHERE` clause). They cannot be selected and cannot
+     be passed as arguments to other functions.
+   - Supported operators include:
 
      ::
 
@@ -412,7 +414,8 @@ functions are rewritten during query optimization to a KQL query that matches th
      Use of other operators (e.g., arithmetic or function calls) with wildcard functions is not allowed and will result
      in a query error.
 
-Examples:
+Examples
+--------
 
 .. code-block:: sql