Re: [PATCH] pg_permissions

On 03/09/21 11:11, Joel Jacobson wrote:
> On Tue, Mar 9, 2021, at 07:34, Joel Jacobson wrote:
>> On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote:
>>> 1. Is there a reason not to make 'grantor' and 'grantee' of type regrole?
>
> Having digested your idea, I actually agree with you.
>
> Since we have the regrole-type, I agree we should use it,
> even though we need to cast, no biggie.

This does highlight [topicshift] one sort of
inconvenience I've observed before in other settings: how fussy
it may be to write WHERE grantee = 'bob' when there is no user 'bob'.

A simple cast 'bob'::regrole raises undefined_object (in class
"Syntax Error or Access Rule Violation") rather than just returning
no rows because no grantee is bob.

It's a more general issue: I first noticed it when I had proudly
implemented my first PostgreSQL type foo that would only accept
valid foos as values, and the next thing that happened was my
colleague in frontend development wrote mean Python comments about me
because he couldn't simply search for a foo in a table without either
first duplicating the validation of the value or trapping the error
if the user had entered a non-foo to search for.

We could solve that, of course, by implementing = and <> (foo,text)
to simply return false (resp. true) if the text arg isn't castable
to foo.

But the naïve way of writing such an operator repeats the castability
test for every row compared. If I were to build such an operator now,
I might explore whether a planner support function could be used
to check the castability once, and replace the whole comparison with
constant false if that fails.

And this strikes me as a situation that might be faced often enough
to wonder if some kind of meta-support-function would be worth supplying
that could do that for any type foo.
[/topicshift]

Regards,
-Chap