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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
