Re: Permissions checks for range-type support functions

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Robert Haas's message of mi nov 23 11:01:50 -0300 2011:
>> It's always seemed mildly insane to me that we don't distinguish
>> between different flavors of "internal". That seems like an accident
>> waiting to happen.

> Well, before we had INTERNAL, there was only OPAQUE which conflated even
> more things that we now distinguish (at least trigger and cstring, not
> sure if there were others).

Yeah, we previously subdivided OPAQUE to get rid of exactly this type of
problem. Not sure if it's worth going further.

The case that would be problematic would be if we had two different
calling contexts that invoked internal-using functions, both accessible
for untrusted users to set up which function gets called, and sharing
identical function signatures. ATM I believe the only calling contexts
that untrusted users can control are operator selectivity functions
(restriction and join flavors) and encoding conversion functions;
and those three cases have signatures that are distinct from each other
and from all privileged cases. But this certainly is something that
could accidentally get broken in future.

I don't think we want to split INTERNAL into the number of distinct
pseudotypes that would be required to cover everything, but it might
be worth inventing a couple more for the selectivity cases, if we ever
change those APIs again.

regards, tom lane