Consistently spell "leakproof" without a hyphen.
authorDean Rasheed <[email protected]>
Tue, 14 Jan 2025 13:50:54 +0000 (13:50 +0000)
committerDean Rasheed <[email protected]>
Tue, 14 Jan 2025 13:50:54 +0000 (13:50 +0000)
The overwhelming majority of places already did this, but a small
handful of places had a hyphen.

Yugo Nagata.

Discussion: https://postgr.es/m/CAEZATCXnnuORE2BoGwHw2zbtVvsPOLhbfVmEk9GxRzK%2Bx3OW-Q%40mail.gmail.com

doc/src/sgml/catalogs.sgml
doc/src/sgml/planstats.sgml
doc/src/sgml/rules.sgml
src/backend/statistics/extended_stats.c
src/backend/utils/adt/selfuncs.c
src/include/catalog/pg_proc.h

index 238ed67919085bf62a1fb54035a61cbbf052b769..d3036c5ba9d609dac80737fd3c009d16be933e4c 100644 (file)
@@ -6040,7 +6040,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
        The function has no side effects.  No information about the
        arguments is conveyed except via the return value.  Any function
        that might throw an error depending on the values of its arguments
-       is not leak-proof.
+       is not leakproof.
       </para></entry>
      </row>
 
index 4fcfdc6e6211b20f33b867a9221e0db8339c1758..a909a5e313460fede8527197e65a68cc55a2a953 100644 (file)
@@ -740,7 +740,7 @@ EXPLAIN (ANALYZE, TIMING OFF, BUFFERS OFF) SELECT * FROM t WHERE a &lt;= 49 AND
    error, in which case this mechanism is invisible in practice.  But if the
    user is reading from a security-barrier view, then the planner might wish
    to check the statistics of an underlying table that is otherwise
-   inaccessible to the user.  In that case, the operator should be leak-proof
+   inaccessible to the user.  In that case, the operator should be leakproof
    or the statistics will not be used.  There is no direct feedback about
    that, except that the plan might be suboptimal.  If one suspects that this
    is the case, one could try running the query as a more privileged user,
index 2b14db054de667676a277f0d10a169c91c3cc0ba..7e98f5694b448ce6b860135e8a8a666a223e93ca 100644 (file)
@@ -2162,7 +2162,7 @@ CREATE VIEW phone_number WITH (security_barrier) AS
     <literal>LEAKPROOF</literal> to be pushed down, as they never receive data
     from the view.  In contrast, a function that might throw an error depending
     on the values received as arguments (such as one that throws an error in the
-    event of overflow or division by zero) is not leak-proof, and could provide
+    event of overflow or division by zero) is not leakproof, and could provide
     significant information about the unseen rows if applied before the security
     view's row filters.
 </para>
index 34dcb535e1865d0720c7ac7f120079fd447b7617..a8b63ec0884a987b7fc8862f9c7181313f28d115 100644 (file)
@@ -1397,7 +1397,7 @@ statext_is_compatible_clause_internal(PlannerInfo *root, Node *clause,
                /*
                 * If there are any securityQuals on the RTE from security barrier
                 * views or RLS policies, then the user may not have access to all the
-                * table's data, and we must check that the operator is leak-proof.
+                * table's data, and we must check that the operator is leakproof.
                 *
                 * If the operator is leaky, then we must ignore this clause for the
                 * purposes of estimating with MCV lists, otherwise the operator might
@@ -1464,7 +1464,7 @@ statext_is_compatible_clause_internal(PlannerInfo *root, Node *clause,
                /*
                 * If there are any securityQuals on the RTE from security barrier
                 * views or RLS policies, then the user may not have access to all the
-                * table's data, and we must check that the operator is leak-proof.
+                * table's data, and we must check that the operator is leakproof.
                 *
                 * If the operator is leaky, then we must ignore this clause for the
                 * purposes of estimating with MCV lists, otherwise the operator might
index 93e4a8906c51c41c5794825ac5bd5f3d35c7e281..d3d1e485bb2559393e9476ac4b874b7899b0bf76 100644 (file)
@@ -5763,7 +5763,7 @@ examine_simple_variable(PlannerInfo *root, Var *var,
  * Check whether it is permitted to call func_oid passing some of the
  * pg_statistic data in vardata.  We allow this either if the user has SELECT
  * privileges on the table or column underlying the pg_statistic data or if
- * the function is marked leak-proof.
+ * the function is marked leakproof.
  */
 bool
 statistic_proc_security_check(VariableStatData *vardata, Oid func_oid)
@@ -5778,7 +5778,7 @@ statistic_proc_security_check(VariableStatData *vardata, Oid func_oid)
                return true;
 
        ereport(DEBUG2,
-                       (errmsg_internal("not using statistics because function \"%s\" is not leak-proof",
+                       (errmsg_internal("not using statistics because function \"%s\" is not leakproof",
                                                         get_func_name(func_oid))));
        return false;
 }
index fdb1e2807115df463ca9db60fc445b4ddca4bc67..b34b00aa3ea3a66012701f11ba7038f65709d29e 100644 (file)
@@ -61,7 +61,7 @@ CATALOG(pg_proc,1255,ProcedureRelationId) BKI_BOOTSTRAP BKI_ROWTYPE_OID(81,Proce
        /* security definer */
        bool            prosecdef BKI_DEFAULT(f);
 
-       /* is it a leak-proof function? */
+       /* is it a leakproof function? */
        bool            proleakproof BKI_DEFAULT(f);
 
        /* strict with respect to NULLs? */