Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)

On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> I marked the default leakproof function according to the criteria that
> does not leak contents of the argument.
> Indeed, timestamp_ne_timestamptz() has a code path that rises
> an error of "timestamp out of range" message. Is it a good idea to
> avoid mark "leakproof" on these functions also?

I think that anything which looks at the data and uses that as a basis
for whether or not to throw an error is non-leakproof.  Even if
doesn't directly leak an arbitrary value, I think that leaking even
some information about what the value is no good.  Otherwise, you
might imagine that we would allow /(int, int), because it only leaks
in the second_arg = 0 case.  And you might imagine we'd allow -(int,
int) because it only leaks in the case where an overflow occurs.  But
of course the combination of the two allows writing something of the
form 1/(a-constant) and getting it pushed down, and now you have the
ability to probe for an arbitrary value.  So I think it's just no good
to allow any leaking at all: otherwise it'll be unclear how safe it
really is, especially when combinations of different functions or
operators are involved.

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