Inspect function privileges

[michaelbeaumont]

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 new SELECT.

[michaelbeaumont]

@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.
thanks for migra!

[djrobstep]

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:

grant execute on function "public"."citext" to "rob";

grant execute on function "public"."citext" to "PUBLIC";

These are redundant in multiple ways.

We need to:

• ignore extension-owned functions
• ignore things that haven't changed
• ignore builtins (unless they've actually changed)
• ignore grants to the database owner who has permissions automatically anyway

Are you comfortable adding this stuff? There should be examples of similar in other entities. Let me know if you have any questions.

[michaelbeaumont]

Thanks! I'll handle it

[michaelbeaumont]

Argh, sorry I haven't gotten around to this yet. I will take a look again within the next couple of weeks.

[michaelbeaumont]

@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?

• ignore things that haven't changed
• ignore builtins (unless they've actually changed)

Shouldn't migra handle the diffing? Or do you mean things that migra would see as having changed even though the privileges are ultimately the same?

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?

[michaelbeaumont]

Superseded by #67