-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/14/2015 03:46 AM, Dean Rasheed wrote:
> I think the docs for the LEAKPROOF option in create_function.sgml
> ought to mention RLS as well as security barrier views. Also the
> current text is no longer strictly correct in light of commit
> dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording
> attached.
Any objections out there to this doc patch? It rings true and reads
well to me. I'd like to check another item off the 9.5 Open Items list..
.
- --
Joe Conway
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVuWXbAAoJEDfy90M199hlVMkP/RO2Vn8hlslKfP+9ZxgCOQk+
YZPlufD10tvsiWtmjxM/czQVgc4OtzANLS4G9tSL0ICiINWckP8FtF6NLdykic17
inTG3wrU2Q/EH9eIio6RJg6iZ+619A21IrFQwlSOJWB1WlPHHdzUoL2YZJsviEyt
01XTb6P60yg11MENWZGKQzWhL0SgjtWliuI2OVb2UbpE2lHb4KBVyPtnn4LW8SyP
a7lJA7WeERAuwlt2C9EbywE1gDJCMOnVnBWHjKtc8fEQKjJGwi6MgXelGBE9QWlx
j2TTleHO270m20aXkIaz/LQX1fjpHonWgtwnW11v4IvGHXZLgN89NRdx2rndBs9z
lRl0t7DLQ0Fn+h6nB4RQdN8huJD12O8JEYvktYMHPjJrCVKgezxqw2e3xUBdCnU+
4eo0TrjQQKxzlQvqTc+dnKXWu/xgre6QNjS5AknoKqA6+MXtCQ6OW/uUKQNA8Amc
WcxjsIJZaLbqOAaODL9DhdufcCCL1rMWuAWAGH7tJwDeIRJOQDChQp5Dg2YmGU/Y
hYAH+bqvJPoo0kAsftgyVocdfp7rDGd3nP87Bg3fFLXobghNIXK1xpXe08IRhAEh
wdMT1Np91WNl9wCyOpUiFn9rmP4ZMALofbhofI5hIsj5dTXvMGxbvsDk7xMykujk
3CeKshcZK060TSo1G2Up
=9wOA
-----END PGP SIGNATURE-----
diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml
new file mode 100644
index c5beb16..cc2098c
--- a/doc/src/sgml/ref/create_function.sgml
+++ b/doc/src/sgml/ref/create_function.sgml
@@ -350,9 +350,18 @@ CREATE [ OR REPLACE ] FUNCTION
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
+ values in any error message, is not leakproof. This affects how the
+ system executes queries against views created with the
+ <literal>security_barrier</literal> option or tables with row level
+ security enabled. The system will enforce conditions from security
+ policies and security barrier views before any user-supplied conditions
+ from the query itself that contain non-leakproof functions, in order to
+ prevent the inadvertent exposure of data. Functions and operators
+ marked as leakproof are assumed to be trustworthy, and may be executed
+ before conditions from security policies and security barrier views.
+ In addtion, functions which do not take arguments or which are not
+ passed any arguments from the security barrier view or table do not have
+ to be marked as leakproof to be executed before security conditions. See
<xref linkend="sql-createview"> and <xref linkend="rules-privileges">.
This option can only be set by the superuser.
</para>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
