On Tue, Aug 11, 2015 at 09:27:17AM -0500, Ted Toth wrote:
> I built an index on a jsonb column of a table with RLS enabled but it
> was not being used. Turns out the the function jsonb_contains needed
> to be LEAKPROOF (thanks Joe Conway). However I do not actually know if
> jsonb_contains is LEAKPROOF.
It is not; check with a query like this: SELECT proleakproof FROM pg_proc WHERE oid = 'jsonb_contains'::regproc;
> Who's responsibility is it to insure
> functions are leakproof?
Nobody in particular is responsible for that. The current set of functions
marked LEAKPROOF consists mostly of comparison functions that were simple to
audit for leakproofness. (The original patch introducing LEAKPROOF did almost
all those audits.) I see no obvious reason for jsonb_contains/jsonb_contained
not to become LEAKPROOF, but they aren't simple to audit.
> It would be useful if this function was
> documented and there was an indication as to it's leakproofness.
The "@>" operator is the documented interface to this functionality; a future
major release could remove jsonb_contains without notice. We don't document
leakproofness or volatility of any function; I think that would crowd the
documentation too much.
Thanks,
nm