1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-20 15:22:23 +03:00

Allow LEAKPROOF functions for better performance of security views.

We don't normally allow quals to be pushed down into a view created
with the security_barrier option, but functions without side effects
are an exception: they're OK.  This allows much better performance in
common cases, such as when using an equality operator (that might
even be indexable).

There is an outstanding issue here with the CREATE FUNCTION / ALTER
FUNCTION syntax: there's no way to use ALTER FUNCTION to unset the
leakproof flag.  But I'm committing this as-is so that it doesn't
have to be rebased again; we can fix up the grammar in a future
commit.

KaiGai Kohei, with some wordsmithing by me.
This commit is contained in:
Robert Haas
2012-02-13 22:20:27 -05:00
parent 2bbd88f8f8
commit cd30728fb2
28 changed files with 3329 additions and 2427 deletions

View File

@ -4423,6 +4423,18 @@
function)</entry>
</row>
<row>
<entry><structfield>proleakproof</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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 leakproof.
</entry>
</row>
<row>
<entry><structfield>proisstrict</structfield></entry>
<entry><type>bool</type></entry>

View File

@ -33,7 +33,7 @@ ALTER FUNCTION <replaceable>name</replaceable> ( [ [ <replaceable class="paramet
<phrase>where <replaceable class="PARAMETER">action</replaceable> is one of:</phrase>
CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
IMMUTABLE | STABLE | VOLATILE
IMMUTABLE | STABLE | VOLATILE | LEAKPROOF
[ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
COST <replaceable class="parameter">execution_cost</replaceable>
ROWS <replaceable class="parameter">result_rows</replaceable>
@ -191,6 +191,17 @@ ALTER FUNCTION <replaceable>name</replaceable> ( [ [ <replaceable class="paramet
</listitem>
</varlistentry>
<varlistentry>
<term><literal>LEAKPROOF</literal></term>
<listitem>
<para>
Change whether the function is considered leakproof or not.
See <xref linkend="sql-createfunction"> for more information about
this capability.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>COST</literal> <replaceable class="parameter">execution_cost</replaceable></term>

View File

@ -26,7 +26,7 @@ CREATE [ OR REPLACE ] FUNCTION
| RETURNS TABLE ( <replaceable class="parameter">column_name</replaceable> <replaceable class="parameter">column_type</replaceable> [, ...] ) ]
{ LANGUAGE <replaceable class="parameter">lang_name</replaceable>
| WINDOW
| IMMUTABLE | STABLE | VOLATILE
| IMMUTABLE | STABLE | VOLATILE | LEAKPROOF
| CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
| [ EXTERNAL ] SECURITY INVOKER | [ EXTERNAL ] SECURITY DEFINER
| COST <replaceable class="parameter">execution_cost</replaceable>
@ -324,6 +324,23 @@ CREATE [ OR REPLACE ] FUNCTION
</listitem>
</varlistentry>
<varlistentry>
<term><literal>LEAKPROOF</literal></term>
<listitem>
<para>
<literal>LEAKPROOF</literal> indicates that the function has no side
effects. It reveals no information about its arguments other than by
its return value. For example, a function which throws an error message
for some argument values but not others, or which includes the argument
values in any error message, is not leakproof. The query planner may
push leakproof functions (but not others) into views created with the
<literal>security_barrier</literal> option. See
<xref linkend="sql-createview"> and <xref linkend="rules-privileges">.
This option can only be set by the superuser.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CALLED ON NULL INPUT</literal></term>
<term><literal>RETURNS NULL ON NULL INPUT</literal></term>

View File

@ -1890,6 +1890,20 @@ CREATE VIEW phone_number WITH (security_barrier) AS
enabled by default.
</para>
<para>
The query planner has more flexibility when dealing with functions that
have no side effects. Such functions are referred to as LEAKPROOF, and
include many simple, commonly used operators, such as many equality
operators. The query planner can safely allow such functions to be evaluated
at any point in the query execution process, since invoking them on rows
invisible to the user will not leak any information about the unseen rows.
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) are not leak-proof, and could provide
significant information about the unseen rows if applied before the security
view's row filters.
</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