Access to the table
pg_statistic is restricted to superusers, so
that ordinary users cannot learn about the contents of the tables
of other users from it. Some selectivity estimation functions
will use a user-provided operator (either the operator appearing
in the query or a related operator) to analyze the stored
statistics. For example, in order to determine whether a stored
most common value is applicable, the selectivity estimator will
have to run the appropriate
operator to compare the constant in the query to the stored
value. Thus the data in
pg_statistic is potentially passed to
user-defined operators. An appropriately crafted operator can
intentionally leak the passed operands (for example, by logging
them or writing them to a different table), or accidentally leak
them by showing their values in error messages, in either case
possibly exposing data from
pg_statistic to a user who should not be able
to see it.
In order to prevent this, the following applies to all
built-in selectivity estimation functions. When planning a query,
in order to be able to use stored statistics, the current user
must either have
SELECT privilege on
the table or the involved columns, or the operator used must be
LEAKPROOF (more accurately, the
function that the operator is based on). If not, then the
selectivity estimator will behave as if no statistics are
available, and the planner will proceed with default or fall-back
If a user does not have the required privilege on the table or columns, then in many cases the query will ultimately receive a permission-denied 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 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, to see if a different plan results.
This restriction applies only to cases where the planner would
need to execute a user-defined operator on one or more values
pg_statistic. Thus the
planner is permitted to use generic statistical information, such
as the fraction of null values or the number of distinct values
in a column, regardless of access privileges.
Selectivity estimation functions contained in third-party extensions that potentially operate on statistics with user-defined operators should follow the same security rules. Consult the PostgreSQL source code for guidance.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.