Comment 4 for bug 1438896

Fixed the problem with returning internal error - the objectUID check was not working correctly.

While debugging this problem, I noticed that once DB__ROOT, or someone granted DB__ROOTROLE becomes the owner after the replace view executes.

Connect as user1:

Create shared schema abc;
Create table abc.t1;
Create view abc.v1 as select from t1;

Connect as db__root

Create or replace view abc.v1 as ….

After the replace view, DB__ROOT owns the view.
For private schemas, the user1 owns the view after replace completes.

So should replace view in a shared schema retain the original ownership or grant it to the person executing the replace command?

Some comments:

Paul - It make sense to think of it as two separate commands (a DROP followed by a CREATE), so I think there should be a new owner. The second owner has the privilege to DROP.

Cliff - I think the person executing the create or replace should be the owner. Otherwise, sometimes the owner will be the second user, other times the first user. That seems harder to manage. In private schemas, owner is consistently the schema owner/original view owner ==> However, DB__ROOT could be a special case, as other commands have DB__ROOT acting on behalf of the owner.

For now, we won't change the behavior.