Beginning SQL

Chapter 12
Privileges
Privileges are the ability to perform some action on some object. The SQL1 standard defines only privileges
on tables and views and thus defines only four basic privileges that work on these objects:
❑ The SELECT privilege allows the user to create data sets of columns and rows from tables or
views. With this privilege, the user can specify a view or table name in the FROM clause of a
SELECT query. The SELECT privilege means that the user is allowed to view or use data from
the table or view on which the SELECT privilege is granted.
❑ The INSERT privilege allows the user to insert new rows into the table or view on which the
INSERT privilege is granted; thus they can use that table or view name in the INTO clause of an
INSERT statement.
❑ The DELETE privilege allows the user to delete rows from the table or view on which the DELETE
privilege is granted; thus they can use the name of that table or view in the FROM clause of a
DELETE statement.
❑ The UPDATE privilege allows the user to update rows from the table or view on which the DELETE
privilege is granted; thus they can use the name of that table or view in the UPDATE statement.
These four privileges are all that the SQL1 standard allowed, and these privileges are implemented in all
commercial SQL-compliant DBMSs.
Extended Privileges
336
SQL2 expanded on the concepts of SQL1 in several ways. First, it added the ability to the INSERT and
UPDATE statements to operate on specific columns instead of on the entire table. Suppose that a new vice
president is hired. The Personnel department is tasked with setting up all new personnel records, entering
the name, address, personnel ID, and so forth. The salary and compensation information is not their
department, however, and they should not have access to this information. Only the personnel manager
is allowed to edit these fields. In SQL1, in order to get this capability, you had to implement views that
retrieved the columns of interest and then use those views in an INSERT or UPDATE statement. Although
this works, it leads to dozens of views whose sole purpose is to enforce security and makes administering
security unnecessarily complex. In SQL2, however, you can directly create INSERT statements that
insert only specific columns of the new record and then UPDATE statements that allow other users to
update the columns for which they are responsible.
Unfortunately, the SQL2 standard does not allow the SELECT statement to specify only selected columns,
so for these statements you are back to creating views that pull specific columns and use them instead of a
SELECT statement on the table directly. Many of the major DBMSs allow applying privileges to columns as
an extension to the SQL2 syntax, using the same syntax as is used in the INSERT and UPDATE statements.
In addition to the new column-specific privileges, the SQL2 standard adds the REFERENCES privilege,
which addresses some rather subtle issues dealing with using foreign keys and check constraints. The
issue here is that by including valid foreign keys in a SQL statement, a user can determine whether
the key is valid or not, even if they are not supposed to have any access to the table from which the foreign
key comes. An INSERT statement can be constructed that successfully inserts a record. Then the
foreign key is added as a column to the statement. If a statement succeeds, the key is valid; if the statement
fails, then the key is not valid. Suppose that the foreign key was the social security number (SSN)
of an employee. The user would now be able to determine whether an employee existed with that
SSN even though they are not supposed to be able to see the SSNs of the Employee table. Likewise,