psql: Add leakproof indicator to \df+, \do+, \dAo+, and \dC+ output.

This allows users to determine whether particular functions are
leakproof, and whether the underlying functions used by operators and
casts are leakproof. This is useful to determine whether indexes can
be used in queries on security barrier views or tables with row-level
security policies.

Yugo Nagata, reviewed by Erik Wienhold and Dean Rasheed.

Discussion: https://postgr.es/m/20240701220817.483f9b645b95611f8b1f65da%40sranhm.sraoss.co.jp

1 files changed, 11 insertions, 0 deletions

diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 7a928bd7b90..2b14db054de 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -2168,6 +2168,17 @@ CREATE VIEW phone_number WITH (security_barrier) AS
 </para>
 
 <para>
+    For example, an index scan cannot be selected for queries on security
+    barrier views (or tables with row-level security policies) if an
+    operator used in the <literal>WHERE</literal> clause is associated with the
+    operator family of the index, but its underlying function is not marked
+    <literal>LEAKPROOF</literal>. The <xref linkend="app-psql"/> program's
+    <command><link linkend="app-psql-meta-command-dao">\dAo+</link></command>
+    meta-command is useful to list operator families and determine which of
+    their operators are marked as leakproof.
+</para>
+
+<para>
     It is important to understand that even a view created with the
     <literal>security_barrier</literal> option is intended to be secure only
     in the limited sense that the contents of the invisible tuples will not be