On Wed, Aug 9, 2017 at 10:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Scott Marlowe <scott.marlowe@gmail.com> writes: > Seems like something that should be handled by alter doesn't it?
I have some vague memory that we intentionally didn't implement ALTER EXTENSION OWNER because we were unsure what it ought to do about ownership of objects belonging to the extension. If the answer is "nothing" then it wouldn't be hard to add such a statement.
The documented contract of CREATE EXTENSION(1)/ALTER EXTENSION ADD MEMBER(2) requires that the extension owner and the owner of the member objects be one-and-the-same (I suppose the inclusion of DROP in (2) makes this debatable). I do not know what happens today if someone tries to ALTER OBJECT SET OWNER on a member object to a role other than the owner of the extension. From the docs I'd suggest that it should fail. Likewise, ALTER EXTENSION OWNER should cascade to all members - which (3), and normal dependency tracking, seems to make straight-forward.
1>The user who runs CREATE EXTENSION becomes the owner of the extension for purposes of later privilege checks, as well as the owner of any objects created by the extension's script.
2>You must own the extension to use ALTER EXTENSION. The ADD/DROP forms require ownership of the added/dropped object as well.
3>CREATE EXTENSION additionally records the identities of all the created objects, so that they can be dropped again if DROP EXTENSION is issued.
