On 03.12.2019 23:43, Stephen Frost wrote:
> Greetings,
>
> * Konstantin Knizhnik (k.knizhnik@postgrespro.ru) wrote:
>> Numeric functions are not marked as leakproof in pg_proc.dat
>> It cause unexpected behavior in case of using row-level security:
> The behavior you're getting is *entirely* expected, just to be clear.
> Perhaps unfortunate and not as performant as you were hoping, but
> definitely not unexpected.
>
> As Tom noted downthread, you can't just mark things 'leakproof' because
> you want them to be able to be used in an index- you need to actually
> show that they're leakproof.
>
>> I have not checked all other builtin type.
>> But it seems to me that it may be reasonable to mark ALL builtin functions
>> (described in pg_proc.dat) as leekprof by default.
> Absolutely not without careful verification of each and every one.
> There's nothing that guarantees builtins are leakproof (and indeed,
> there's no shortage of ones that are clearly *not* leakproof today).
>
> I'd love it for someone to go through and fix them all to actually be
> leakproof (or at least all of the ones that might be used with an index)
> but that clearly hasn't been done here.
Ok, I understand that it is not possible just to mark all built-in
functions as leak proof, but what about
marking as leakproof just comparison functions for the numeric type as I
proposed in the attached patch?
I have checked that cmp_numerics can not report any errors and so it can
be considered as leekprof as far as comparison functions for most of
other builtin types
which are already marked as leakproof.
After applying this patch opr_sanity test is failed (just because list
of leakproof functions is extended, so expected result for this test
should also be updated).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company