On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <noah@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.