Re: When and where to check for function permissions

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> We do not resolve table names that way, why should we resolve function
>> names?

> We do not resolve table names at all.

The point is that a table you can't currently access isn't invisible.

It'd be even weirder if it were visible for some operation types and not
others. Among other things, that would break rules on views: you can
never insert into a view, so if we adopted the spec's viewpoint, you
could never see a view as target of INSERT and would thus never advance
to the next step of looking for a rewrite rule for it.

Here's another example that should give you pause: let's assume there's
an UPDATE access right for functions that controls whether you can
update the function definition (via CREATE OR REPLACE). Let's further
suppose that you have execute but not update access to function foo(int).

test=> select foo(2);
-- works fine

test=> create or replace foo(int) ... etc etc ...;

If we follow the spec's lead, then CREATE OR REPLACE doesn't see the
existing definition at all (because it doesn't have the correct access
rights), and so instead of the expected update, you get a new function
definition. This might even appear to work, from your point of view,
if the new definition gets entered into a namespace closer to the front
of your search path than the original was. But other people will
continue to see the old definition if they don't share your path.

The implications for ambiguous-function resolution would be no less
bizarre and unhelpful.

You could *maybe* get away with visibility-depends-on-access-rights
in a world with no name search paths and no function name overloading
(although why you'd bother is not quite clear to me). In the presence
of those features, doing it the spec's way is sheer folly.

I would also ask for some positive reason why we should do this the
spec's way; what actual user benefit does it provide to make uncallable
functions invisible? I don't see one; all I see is user confusion.

> You could say Unix shells
> are brain-dead, too, because they do the same thing.

They do? How so? Last I checked, trying to execute a program I didn't
have exec rights to gave "no permissions", not "not found", and
certainly not "use the next one down the PATH instead".

regards, tom lane