>> - How does the above point affect full dumps that include schema and
>>data? In my proposal, the copy commands will run as the user running
>>the script, not the table owner anymore. Presumably, the user running
>>the script is a superuser. Given that it is possible for a table owner
>>to revoke their own INSERT privilege on their table, the existing
>>behaviour is broken anyway.
>
> This is why GRANT/REVOKE has to be postponed to the end. I think it
> would be a lot simpler and more reliable if you also postponed ALTER
> OWNER.
Ok, I have thought about this a bit and I have decided that you are
right in that grant revoke MUST be deferred to the end of the file.
The reason is that there are two conditions under which we expect a dump
restore to work. First is if you are restoring as a superuser second is
if you are restoring as a user who owns ALL the objects in the file.
Restoring as superuser will work so long as we use alter owner instead
of changing the current user.
The second is more tricky due to the fact that an object owner can
revoke their own privileges from their objects. If a user does this, it
cannot be guaranteed that they will be able to restore unless all grants
are done last and all objects are initially created as that user.
Consider revoking your own REFERENCES privilege, as an example.
Hence, I will have to make it that all existing dumping is done, then
all the ownership changes will be done, then all the grants will be done.
Does that seem reasonable?
Chris
