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
