On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote: > > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <n...@leadboat.com> wrote: > > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient > > > >> for > > > >> setting LEAKPROOF.
> I'm not really sure that attaching it to pg_read_all_data makes sense.. > > In general, I've been frustrated by the places where we lump privileges > together rather than having a way to distinctly GRANT capabilities > independently- that's more-or-less exactly what lead me to work on > implementing the role system in the first place, and later the > predefined roles. This would be no more lumpy than e.g. pg_read_all_stats. However, I could live with a separate pg_change_leakproof (or whatever name). > Here's what I'd ask Andrey- what's the actual use-case here? Are these > cases where users are actually adding new functions which they believe > are leakproof where those functions don't require superuser already to > be created? Clearly if they're in a untrusted language and you have to > be a superuser to install them in the first place then they should just > mark the function as leakproof when they install it. If these are > trusted language functions, I'd be curious to actually see them as I > have doubts about if they're actually leakproof.. > > Or is the actual use-case here that they just want to mark functions we > know aren't leakproof as leakproof anyway because they aren't getting > the performance they want? Hearing those answers would be interesting, but it shouldn't change decisions. A reasonable person can write an actually-leakproof function and wish to mark it LEAKPROOF, independent of whether that happened in the case that prompted this thread.
