-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inspect function privileges #44
Conversation
d6d6579
to
0628847
Compare
@djrobstep do you have time to take a look if this makes any sense? Lack of comprehensive privilege support (djrobstep/migra#64) is making privilege changes a little tedious for us atm. |
Hey, thanks for this PR, much appreciated! I actually took a look at this a few days back, and meant to get back to you. Unfortunately this can't be merged yet as when I test it with migra it results in lots of extraneous grants in the following form:
These are redundant in multiple ways. We need to:
Are you comfortable adding this stuff? There should be examples of similar in other entities. Let me know if you have any questions. |
Thanks! I'll handle it |
Argh, sorry I haven't gotten around to this yet. I will take a look again within the next couple of weeks. |
0628847
to
ff5e246
Compare
@djrobstep I've skipped the DB owner grant now. Do you know a reliable way to determine if a function was created by an extension?
Shouldn't For the second point, that would essentially require "knowing" the default builtin permissions and only outputting something if there's a deviation from the default, correct? |
ff5e246
to
16b0d84
Compare
Superseded by #67 |
Part of djrobstep/migra#64
One thing I'm not sure about is why it's correct to filter out grants to the table owner in the first
SELECT
statement and therefore I've left it out of the newSELECT
.