database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-03 20:02:46 +03:00
Code Activity

Allow LEAKPROOF functions for better performance of security views.

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

19
doc/src/sgml/ref/create_function.sgml
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>