Privileges when creating a view

The database server tests to make sure that you have all the privileges that are required to execute the SELECT statement in the view definition. If you do not, the database server does not create the view.

This test ensures that users cannot create a view on the table and query the view to gain unauthorized access to a table.

After you create the view, the database server grants you, the creator and owner of the view, at least the Select privilege on it. No automatic grant is made to PUBLIC, as is the case with a newly created table.

The database server tests the view definition to see if the view is modifiable. If it is, the database server grants you the Insert, Delete, and Update privileges on the view, provided that you also have those privileges on the underlying table or view. In other words, if the new view is modifiable, the database server copies your Insert, Delete, and Update privileges from the underlying table or view and grants them on the new view. If you have only the Insert privilege on the underlying table, you receive only the Insert privilege on the view.

This test ensures that users cannot use a view to gain access to any privileges that they did not already have.

Because you cannot alter or index a view, the Alter and Index privileges are never granted on a view.

This section does not apply to views on remote tables. Permissions on remote tables are not propagated automatically to views on those tables. To provide PUBLIC with Select access to a view that includes one or more columns in a remote table, for example, you must explicitly execute REVOKE ALL FROM PUBLIC for the view, and then explicitly grant Select privilege on that view to PUBLIC.