Re: leakproof

On Sun, Feb 19, 2012 at 10:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Don Baccus <dhogaza(at)pacifier(dot)com> writes:
>> On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:
>>> Hmm, "pure" doesn't sound bad to me.  Nice and short.
>
>> Technically, "pure" is stronger than "has no side effects":
>> http://en.wikipedia.org/wiki/Pure_function
>> Result can't depend on state (for instance, database contents), either.  This is the typical definition used in functional programming.
>
> Well, that condition is subsumed in our idea of an immutable function.
> It's not clear to me whether pure/leakproof functions are meant to be a
> strict subset of immutable functions, but if they are then they meet
> this stricter definition.  On the other hand, if pure/leakproof functions
> don't have to be immutable but only stable, then the stricter definition
> corresponds to "pure immutable".  That still doesn't sound too bad, as
> long as we define our terms clearly in the docs.

For the present application (pushdown into security views), we really
only care whether the function has side effects, such as throwing an
error or mutating global state. So, in theory, even a volatile
function could be leakproof - it could read (but not write) some piece
of global, volatile state. In practice, I'm not sure those cases are
important at all. Right now, the only things marked as leakproof are
relational operators that might be indexable, precisely so that we
might be able to push an indexable qual down far enough to allow an
index scan, even in the presence of an intervening security view.
Maybe someone will want to push down a qual like x > now() or x >
clock_timestamp(), but I guess I can't get that excited about that.
There are so few leakproof functions that the chances of making
pushdown work safely for much of anything beyond col = const seem
remote. So, my tea leaves are telling me that if we want to make pure
a subset of immutable, that probably isn't going to cause a problem.
However, I am not a CTLR (certified tea leaf reader).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company