Teradata Database SQL Data Control Language User Manual
Below you will find brief information for Teradata Database 13.0. This manual describes the SQL language statements used to assign or revoke access to data, the SQL Data Control Language. It details privileges, owners, and how to secure your Teradata database.
Advertisement
Advertisement
Teradata Database
SQL Data Control Language
Release 13.0
B035-1149-098A
April 2009
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce,
SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You’ve Never Seen Your Business Like
This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc.
EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of GoldenGate Software, Inc.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
Intel, Pentium, and XEON are registered trademarks of Intel Corporation.
IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation.
Linux is a registered trademark of Linus Torvalds.
LSI and Engenio are registered trademarks of LSI Corporation.
Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United
States and other countries.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademark of SPARC International, Inc.
Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.
Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries.
Unicode is a collective membership mark and a service mark of Unicode, Inc.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
T
HE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN
“
AS
-
IS
”
BASIS
,
WITHOUT WARRANTY OF ANY KIND
,
EITHER
EXPRESS OR IMPLIED
,
INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY
,
FITNESS FOR A PARTICULAR PURPOSE
,
OR
NON
-
INFRINGEMENT
. S
OME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES
,
SO THE ABOVE EXCLUSION
MAY NOT APPLY TO YOU
. I
N NO EVENT WILL
T
ERADATA
C
ORPORATION BE LIABLE FOR ANY INDIRECT
,
DIRECT
,
SPECIAL
,
INCIDENTAL
,
OR CONSEQUENTIAL DAMAGES
,
INCLUDING LOST PROFITS OR LOST SAVINGS
,
EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES
.
The information contained in this document may contain references or cross-references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions, products, or services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any time without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: [email protected]
Any comments or materials (collectively referred to as “Feedback”) sent to Teradata Corporation will be deemed non-confidential. Teradata
Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata
Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback.
Copyright © 2000 – 2009 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
Audience
This manual describes the SQL language statements used to assign or revoke access to the data. These statements constitute the SQL Data Control Language.
This preface describes the organization of SQL Data Control Language and identifies information you should know before using it. This book should be used in conjunction with the other volumes of the SQL book set.
System administrators, database administrators, and security administrators are the principal audience for this book. Teradata field engineers and other technical personnel responsible for designing and maintaining a Teradata Database may also find this book useful.
Supported Software Release
This book supports Teradata® Database 13.0.
Prerequisites
If you are not familiar with Teradata Database, you will find it useful to read Introduction to
Teradata and SQL Fundamentals before reading this book.
You should be familiar with basic relational database management theory and technology.
This book is not an SQL primer.
SQL Data Control Language 3
4
Preface
Changes To This Book
Changes To This Book
Date
Teradata
Database 13.0
April 2009
Teradata
Database 12.0
September 2007
Description
•
Created the new SQL Data Control Language manual from the previously existing SQL Reference: Data Definition Statements manual and moved the following statements from that manual to this one:
•
GIVE
•
GRANT (Monitor, Role, and SQL forms)
•
GRANT LOGON
•
REVOKE (Monitor, Role, and SQL forms)
•
REVOKE LOGON
•
Added the following new statements:
•
GRANT CONNECT THROUGH
•
REVOKE CONNECT THROUGH
•
Added the following new privileges:
•
CREATE GLOP
•
CREATE OWNER PROCEDURE
•
CTCONTROL
•
DROP GLOP
•
GLOP
•
GLOP MEMBER
•
SHOW
•
STATISTICS
•
Added the capability of granting and revoking the INSERT and SELECT privileges at the column level.
•
Removed the complete list of data dictionary privilege abbreviations from
GRANT (SQL Form).
•
Added a complete list of data dictionary privilege abbreviations to GRANT
(SQL Form).
SQL Data Control Language
Preface
Additional Information
Additional Information
URL
http://www.info.teradata.com/
Description
Use the Teradata Information Products Publishing Library site to:
•
View or download a manual:
1
2
Under Online Publications, select General Search.
Enter your search criteria and click Search.
•
Download a documentation CD-ROM:
1
2
Under Online Publications, select General Search.
In the Title or Keyword field, enter
CD-ROM, and click Search.
•
Order printed manuals:
Under Print & CD Publications, select How to Order.
http://www.teradata.com
The Teradata home page provides links to numerous sources of information about Teradata. Links include:
•
Executive reports, case studies of customer experiences with Teradata, and thought leadership
•
Technical information, solutions, and expert advice
•
Press releases, mentions and media resources http://teradatauniversitynetwork.com
Teradata University Network fosters education on data warehousing, business intelligence (BI) and database administration (DBA).
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: [email protected]
References to Microsoft Windows and Linux
This book refers to “Microsoft Windows” and “Linux.” For Teradata Database 13.0, these references mean:
•
“Windows” is Microsoft Windows Server 2003 64-bit.
•
“Linux” is SUSE Linux Enterprise Server 9 and SUSE Linux Enterprise Server 10.
SQL Data Control Language 5
Preface
References to Microsoft Windows and Linux
6 SQL Data Control Language
Table of Contents
Preface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Chapter 1: Teradata Database Privileges
. . . . . . . . . . . . . . . . . . . . . . . . . .9
SQL Data Control Language 7
Table of Contents
Chapter 2: SQL Data Control Language Statement Syntax
. . .29
Appendix A: Notation Conventions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Glossary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Index
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
8 SQL Data Control Language
CHAPTER 1
Teradata Database Privileges
This chapter describes the fundamental concepts behind Teradata Database privileges, including the following topics:
•
Privileges
•
Owners, Creators, and Users
•
Types of Privileges, including the following:
•
Implicit Privileges
•
Explicit Privileges
•
Automatically Granted Privileges
•
Inherited Privileges
•
PUBLIC Privileges
The SQL statements used to grant and revoke the various privileges supported by Teradata
Database are described in
Chapter 2: “SQL Data Control Language Statement Syntax.”
SQL Data Control Language 9
Chapter 1: Teradata Database Privileges
Privileges
Privileges
Introduction
DCL statements grant, transfer, and revoke the privileges associated with users, databases, and roles. Privileges are sometimes referred to as access rights, permissions, or authorizations.
This documentation uses privileges because that is the term used in the ANSI SQL specifications.
Privileges permit users to perform the following actions:
•
Monitor system-wide performance
•
Perform particular statements and access particular database objects
•
Hold membership in a role
•
Log onto Teradata Database.
A user can acquire a privilege in several ways:
•
Directly by having that privilege explicitly granted on itself.
•
Indirectly by being assigned a role that has that privilege.
•
Temporarily as the immediate owner of a view, macro, or stored procedure it is performing.
•
By being the owner of the object.
This is called an implicit privilege (see “Implicit Privileges” on page 21 ).
The following table lists the sets of DCL statements and describes their basic functions:
This DCL statement type …
GRANT
GRANT (Monitor Form)
GRANT (Role Form)
Performs this function with privileges …
assigns them to specified users, databases, and roles.
.
grants system-wide performance monitoring privileges.
See “GRANT (Monitor Form)” on page 34
.
grants role membership to a user or role.
See “GRANT (Role Form)” on page 38 .
GRANT (SQL Form) grants selected or all privileges to a user or database on a specified database object.
See “GRANT (SQL Form)” on page 41
.
GRANT CONNECT THROUGH grants the ability to connect as a proxy permanent or proxy application proxy user through a specified trusted user.
GRANT LOGON grants privilege to log onto Teradata Database to a user and changes current system logon defaults.
See “GRANT LOGON” on page 93 .
10 SQL Data Control Language
Chapter 1: Teradata Database Privileges
Privileges
This DCL statement type …
REVOKE
REVOKE (Monitor Form)
REVOKE (Role Form)
REVOKE (SQL Form)
Performs this function with privileges …
rescinds them from specified users, databases, and roles.
.
revokes system-wide performance monitoring privileges.
See “REVOKE (Monitor Form)” on page 100
.
revokes membership in a role from a user or role.
See “REVOKE (Role Form)” on page 104
.
revokes selected or all privileges from a user or database on a specified database object.
See “REVOKE (SQL Form)” on page 107 .
REVOKE CONNECT THROUGH revokes the ability to connect as a proxy permanent or proxy application proxy user through a specified trusted user.
REVOKE LOGON revokes the logon privilege from a user.
See “REVOKE LOGON” on page 127
.
GIVE transfers ownership of an object from one user or database to another user or database.
Ownership implies certain privileges, so an ownership change implies implicit changes in privileges as well.
GIVE does not transfer privileges for performance monitoring, roles, or logons.
Storage of Privileges
With the exception of implicit privileges (see
“Summary of Implicit and Explicit Privileges” on page 24
and
“Implicit Privileges” on page 21 ), Teradata Database privileges are stored in the
DBC.AccessRights table in the data dictionary.
Implicit privileges are not stored.
SQL Data Control Language 11
Chapter 1: Teradata Database Privileges
Privileges
Users and Databases
The difference between users and databases in Teradata Database has critical implications for matters related to privileges, and it is important to understand what those differences are. This is particularly true with respect to understanding fully the consequences of implicitly granted privileges.
Formally speaking, the difference between a Teradata user and a Teradata database is that a user has a password and a database does not
1
(see “CREATE USER” in SQL Data Definition
Language for details). You might infer from this that databases are passive objects, while users are active objects. That is only true in the sense that databases cannot perform SQL statements. With respect to the semantics of privileges, databases are not entirely passive (see
“Example Implicit Privileges” on page 21 for an example of this).
12
1. Users can also have default attributes such as time zone, date form, character set, role, and profile, while databases cannot.
SQL Data Control Language
Chapter 1: Teradata Database Privileges
Owners, Creators, and Users
Owners, Creators, and Users
Introduction
With respect to privileges on database objects, Teradata users and databases are categorized as one or more of the following types:
•
Owner
•
Immediate owner
•
Creator
•
Active user
Depending on the context, a Teradata Database user can be one, several, or all of these types simultaneously, while a database can only be an owner or immediate owner. It is important to understand the differences among these types because the accrual of privileges is different for each of them.
Type
Owner
Immediate
Owner
Creator
Definition
Databases and users own their own space and all space that is derived from it.
See
“Owners of Database Objects” on page 15 .
Ownership extends downward throughout the user/database space hierarchy. For example, user DBC owns all database objects in a Teradata Database system because all user space derives from DBC. As a result, a database object can have multiple owners.
An owner does not own itself. For example, suppose there is a database named dbl.
Database dbl cannot also be an owner of database dbl.
Owners can grant or revoke privileges to themselves on any objects they own.
Owners implicitly hold the WITH GRANT OPTION on the objects they own. See the
scenario documented in “Privileges and the Accessibility of Data By Means of a View,
Macro, or Stored Procedure” on page 19 for an important consequence of this.
See Database Administration for a description of ownership in a Teradata Database.
A database or user from whose space a database object is created or given is called the immediate owner of that object.
A user who performs the DDL to create a database object is called the creator of that object.
See
“Owners of Database Objects” on page 15 .
Creators are automatically granted privileges on the database objects they create.
Databases can never be creators.
The creator of all objects created in a proxy connection is the trusted user, not the proxy user.
SQL Data Control Language 13
Chapter 1: Teradata Database Privileges
Owners, Creators, and Users
Type Definition
Active user A user who is logged onto a session and is performing requests, either directly or by means of views, macros, stored procedures, or external authentication.
Active users fall into two general categories:
•
Permanent
A permanent user is a database user defined in Teradata Database by a CREATE
USER request. A permanent user always has a password, and can optionally be defined to have permanent space, a default database, a default role, a default profile, and other attributes.
•
Externally authenticated
An externally authorized user cannot have permanent disk space. Only externally authorized users are mapped to the generic user EXTUSER.
Several subcategories of users can be defined within these categories:
•
Trusted users
A trusted user is a permanent user that has been granted the privilege to assume the identity of a proxy user.
•
Proxy users
A proxy user is a user who accesses Teradata Database using the session of a trusted user. There are two types of proxy users:
•
A Teradata Database permanent user
When a proxy user is a permanent user, its privileges are either those defined for the permanent user or the roles defined for the proxy user in the proxy GRANT
CONNECT privileges (see
“GRANT CONNECT THROUGH” on page 83
).
•
A user whose name is not known to Teradata Database
A proxy user whose name is not known to Teradata Database is referred to as an
application proxy user. The application proxy user can be any user that represents the client connecting to the middle tier such as a client name or an
ATM ID.
Application proxy user names are not defined in Teradata Database, so Teradata
Database cannot validate application proxy user names.
A connection for which the user being validated for privileges and logging is a proxy user is referred to as a proxy connection.
A proxy connection uses the privileges of the proxy user. All other session-level attributes are those of the trusted user. These attributes include the following:
•
Account name
•
Spool allocations
•
Temporary space allocations
Performance management APIs such as MonitorSession and AbortSession continue to identify the session by the trusted user name. Teradata Active System
Management rules are enforced for the trusted user name, not the proxy user.
14 SQL Data Control Language
Chapter 1: Teradata Database Privileges
Owners, Creators, and Users
Owners of Database Objects
The owner of an object is a database or user that is higher than the database or user in the user/database hierarchy.
THE immediate owner of a … IS the user of database …
database object in which the object was created.
The default database is the current database for the creating user, but you can also create an object in a different database if you fully qualify its name in the CREATE statement.
•
user
•
database space from which the PERM space for the user or database is allocated.
The default immediate owner of a user or database is its creator, but the creator can specify a different immediate owning user or database by using the FROM
database_name option of the CREATE DATABASE and CREATE USER statements (see “CREATE DATABASE” and “CREATE USER” in SQL Data
Definition Language).
You can also change ownership using the GIVE statement (see “GIVE” on page 30
).
An object must always have an immediate owner. The immediate owner of one or more objects cannot be dropped. An immediate owner can be dropped only after it no longer owns any objects. However, you can change the immediate owner of a database or user by
submitting a GIVE statement (see “GIVE” on page 30
).
Creators of Database Objects
The creator of an object is the user who submitted the CREATE statement for a database object. Each database object has one and only one creator. Unlike owners, creators can be dropped from the system.
If a CREATE statement is run from within a macro or stored procedure, then the user who ran the macro or stored procedure is the creator of the object.
SQL Data Control Language 15
Chapter 1: Teradata Database Privileges
Owners, Creators, and Users
Summary of the Principles of Creation and Ownership
The basic principles defining a creator, an owner, and an immediate owner are described in the following table:
IF …
you run a CREATE statement that creates a database object
THEN you are …
the creator of that object.
You are not necessarily either an owner, or the
immediate owner, of that object. its immediate owner.
an object is directly beneath you in the user/ database hierarchy you create an object in your own database you create an object in the space of another user
(assuming you have the privilege that allows you to do so) user Admin owns you, and you create an object in your database both the creator and the immediate owner of that object.
the creator of the object.
The database/user in which the object is created is its immediate owner.
the creator of the object.
You are also the immediate owner of the object.
User Admin is also an owner, but not the
immediate owner of the object.
16 SQL Data Control Language
Chapter 1: Teradata Database Privileges
Types of Privileges
Types of Privileges
Introduction
Teradata Database supports two general types of privileges:
•
Implicit
•
Explicit
Definition: Privilege
A privilege is a license to access or manipulate a database object. Teradata Database security uses privileges to control activities such as creating, deleting, and viewing database objects as well as running executable database objects.
Implicit privileges are assumed implicitly because of object ownership.
Explicit privileges are granted in three possible ways:
•
Explicitly
Explicitly granted privileges are granted by means of a GRANT request (see “GRANT” on page 33
).
•
Automatically
Automatically granted privileges are granted by means of performing a CREATE request and creating a database object.
•
Inherited
Inherited privileges are assigned by means of a role (see “CREATE ROLE” in SQL Data
Definition Language). Inherited privileges are a form of Explicit privilege.
The following graphic restates this pictorially:
Explicit
Privilege
Implicit
Privilege
Privilege that you explicitly grant with the GRANT statement.
Privilege that is automatically granted by the system as though a GRANT statement was issued.
Inherited Privilege:
Privilege that is assigned by means of a role.
Privilege for a user who directly or indirectly owns an object.
1101A386
SQL Data Control Language 17
Chapter 1: Teradata Database Privileges
Types of Privileges
Granting Privileges to Others
SQL DCL permits you to grant privileges to another user or database if you are one of the following users:
•
User DBC.
•
An owner of the object.
•
A user having each privilege to be granted.
If the grantee is not the same as the user or database having the privilege being granted, either WITH GRANT OPTION or WITH ADMIN OPTION, as appropriate.
A user might have a privilege by inheriting it from a role as a result of creating a view, macro, or stored procedure.
Conceptually, all privileges are granted in the following form:
2
GRANT privilege_type
ON object
TO user or database or role
WITH GRANT OPTION;
This is true whether the privileges are granted implicitly, automatically, or explicitly.
The determination of whether a user can grant the ability to grant a privilege to other users or databases depends on how the WITH GRANT OPTION clause is specified in the SQL
GRANT statement.
IF you grant a privilege …
WITH GRANT OPTION a but do not specify WITH GRANT OPTION
THEN users …
can grant the privilege to another user.
cannot grant privileges to another user.
a. For roles, the parallel syntax to the WITH GRANT OPTION clause is WITH ADMIN OPTION.
Implicit privileges always have the WITH GRANT OPTION characteristic by default.
System-Granted Privileges
You might see the term system-granted privileges used occasionally. These privileges are granted explicitly by a GRANT statement in a DIP script.
18
2. For roles, the syntax for this clause is WITH ADMIN OPTION.
SQL Data Control Language
Chapter 1: Teradata Database Privileges
Types of Privileges
Privileges and the Accessibility of Data By Means of a View, Macro, or
Stored Procedure
The privileges required for users to access data by means of a view, macro, or stored procedure are different than the privileges required to access the same data directly.
Consider the following example scenario:
•
You define a view v in database d2.
•
The base tables referenced by v are also contained within d2.
•
Any user that performs a SELECT request through v must have the SELECT privilege on v.
•
To permit a user to perform this SELECT request, d2 must also have the SELECT WITH
GRANT OPTION privilege on the base tables the view references.
•
You revoke all explicit database, but not table, privileges from d2 by performing the following REVOKE request:
REVOKE ALL PRIVILEGES ON d2 FROM PUBLIC;
You might wonder if users can access the tables in d2 using v. The answer is yes if they are accessing those tables by means of a view, macro, or stored procedure. In this case, d2 is accessed through v, so when a user with the SELECT privilege on v performs the
SELECT … FROM d2.v
request, the system returns the requested rows.
The reason for this is that d2 owns all the views and tables it contains. Because d2 is the immediate owner of these views and tables, it implicitly has the SELECT WITH GRANT
OPTION privilege on them, and implicitly granted privileges cannot be revoked. The system takes advantage of this to permit users to access data indirectly through views, macros, or stored procedures.
Before users can access a database object directly, they must possess explicit privileges on that object. Direct access to database objects can be controlled tightly by granting or revoking user privileges selectively to either minimize or eliminate it entirely. This ensures that users can neither access data they should not view or update, nor can they do something to an object that would compromise its integrity or the integrity of the database.
The situation is different when users access a database object indirectly by means of a view, macro, or stored procedure. These objects are designed specifically to circumvent direct user access of database objects while still providing them with a method to access selected aspects of the data they contain.
SQL Data Control Language 19
Chapter 1: Teradata Database Privileges
Types of Privileges
To support this scenario, the system permits a DBA to revoke all privileges on a base database object, whether granted explicitly or automatically, to ensure maximum security. At the same time, the immediate owner of a view, macro, or stored procedure implicitly and irrevocably possesses all privileges on those objects. This allows the system to permit users of views, macros, and stored procedures to access data indirectly using the implicit privileges granted to the immediate owner of those objects.
In this case, it is the implicit privileges held by the immediate owner of the view, macro, or stored procedure that control whether a user can perform an action using that view, macro, or stored procedure to access data. The explicitly held or automatically assigned privileges the user has on those objects are not relevant.
20 SQL Data Control Language
Chapter 1: Teradata Database Privileges
Implicit Privileges
Implicit Privileges
Introduction
Implicit privileges are privileges users have on database objects because they own those objects, either directly, because they are their immediate owner, or indirectly. Because of this, implicit privileges are sometimes referred to as ownership privileges.
Characteristics of Implicit Privileges
Implicit privileges have the following characteristics:
•
They cannot be revoked.
•
They are not logged in DBC.AccessRights.
•
They are implied for the owner of an object.
•
They are implied from the system ownership hierarchy.
Duration of Implicit Privileges
A database or user has implicit privileges on an object only as long as the database or user is an owner of the object. However, you can use the GIVE statement to change the ownership hierarchy (see
“Transfer of Space Allocation” on page 31 ). Implicit privileges on an object stop
once the object is dropped.
If John owns SampleTable and revokes all privileges from all users, including himself, then no users, including John, even though he is the owner, can access SampleTable. However, because owning SampleTable means he has implicit privilege on it, John can grant the revoked privileges back to himself at any time.
Example Implicit Privileges
Even though owners have implicit privileges on their objects, they must have explicitly granted privileges on most objects to access them directly. For example, an owner of a table must have the explicitly or automatically granted SELECT privilege on that table to be able to select rows from it.
Owners can grant themselves these privileges on objects they own. For example, suppose I own a table named StatusThroughYesterday that I want to make read-only. Because I own
StatusThroughYesterday, I can revoke UPDATE and DELETE privileges on it from all users, including myself. When I need to update StatusThroughYesterday at the end of the current day,
I can grant the UPDATE and DELETE privileges back to myself, make the necessary updates, and then revoke those privileges once again.
SQL Data Control Language 21
Chapter 1: Teradata Database Privileges
Explicit Privileges
Explicit Privileges
Introduction
An explicitly granted privilege is the license to access an object, a database, or a user as granted by the granting user to a recipient user. To grant privileges explicitly, you muse use the SQL
GRANT statement (see
). For example, the following
GRANT request grants the SELECT privilege on table TestTable in the space belonging to
UserA to the user named UserB:
GRANT SELECT ON UserA.TestTable TO UserB;
The grantor must have the privilege to issue the GRANT request.
Awarding the Privilege to Grant Privileges
A user can award the GRANT option to another user by specifying WITH GRANT OPTION when issuing a GRANT request.
For example, if UserA creates TestTable in his own space and then grants UserB the privilege to select data from that table, UserA can also grant User B the privilege to grant the SELECT privilege to other users. For example:
GRANT SELECT ON UserA.TestTable TO UserB WITH GRANT OPTION;
Now UserB has the privilege to grant SELECT on UserA.TestTable to users UserC, UserD, and so on.
Granting Explicit Privileges Automatically
Teradata Database also grants explicit privileges to a user or database automatically when it creates a new object.
3
For example, the system grants a newly created user the privilege to create a table in his own space automatically, and grants the creator of a table the privilege to
alter or drop that table automatically. Also see “Automatically Granted Privileges” on page 25 .
Table-Level Privileges and Database-Level Privileges
Teradata Database supports two general types of explicit privileges: table-level and database-level. The two levels are not mutually exclusive, and many privileges apply at both levels.
The only exclusively table-level privileges are the following:
•
INDEX
•
REFERENCES
Note that REVOKE ALL does not revoke the INDEX and REFERENCES privileges, so if you want to revoke either or both from a user, you must revoke them explicitly.
22
3. Some of the privileges are granted to the creator and others are granted to the newly created database or user.
SQL Data Control Language
Chapter 1: Teradata Database Privileges
Explicit Privileges
Characteristics of Explicit Privileges
Explicit privileges have the following characteristics:
•
They are stored one row per user per privilege on a database object in the
DBC.AccessRights table. Teradata Database uses this table to verify privileges for a user, database, or role.
•
They are granted explicitly to a user/database on specific objects by another user, or automatically granted to a user/database on objects it creates.
•
They can be granted explicitly to a role. A role is a collection of privileges on database objects (see “CREATE ROLE” in SQL Data Definition Language). A user who is a member of a role can access all the objects on which that role has privileges. One row per role per privilege is stored in the DBC.AccessRights table. Also see
“Inherited Privileges” on page 26
.
•
They can be granted explicitly to PUBLIC. Privileges granted to PUBLIC apply to every valid, and all future, users of the system (see
“PUBLIC Privileges” on page 27 ).
Reporting the Contents of the DBC.AccessRights Table
You can retrieve DBC.AccessRights rows using the DBC.AllRightsV view (see Data Dictionary).
This view returns a report of all users who have explicit privileges and the objects on which those privileges are granted.
SQL Data Control Language 23
Chapter 1: Teradata Database Privileges
Summary of Implicit and Explicit Privileges
Summary of Implicit and Explicit Privileges
The following table summarizes the differences between implicit and explicit privileges:
Privilege
Type
Implicit
Explicit
Description
The set of privileges granted to the owner of a database object. Implicit privileges are
sometimes called ownership privileges. See “Implicit Privileges” on page 21
.
The privilege to grant most privileges on any database, user, or database object they own is implicitly held by an owning user or database.
Implicit privileges are not stored as such in DBC.AccessRights. They are derived based on the database/user ownership hierarchy.
The privilege to grant and regrant privileges on any owned object cannot be revoked directly, but can be transferred to another user or database by means of the GRANT
statement (see “GRANT (SQL Form)” on page 41
).
Implicit privileges are usually not sufficient for owners to access objects they own directly. They must also have the explicit privileges, whether granted automatically or explicitly, to access those objects. See
“Example Implicit Privileges” on page 21
for details.
The set of privileges granted to one user by another user or database by means of an
SQL GRANT statement (see “GRANT (SQL Form)” on page 41
and
), automatically, or by means of a role.
Explicitly granted, automatically granted, and inherited privileges are sometimes grouped together as explicit privileges because the system does not discriminate between them once they have been granted. This is because rows in the
DBC.AccessRights table do not record how their privileges were granted, only that they were granted.
The granting user must itself, either explicitly or implicitly, have any privilege it grants to another user or database WITH GRANT OPTION.
Explicit privileges are inserted into DBC.AccessRights by a GRANT statement that
explicitly specifies a set of privileges on a database object. See “GRANT” on page 33
and “GRANT (SQL Form)” on page 41
.
Explicit privileges can be revoked at any time by any user with the authority to do so.
See
“REVOKE (SQL Form)” on page 107 ).
24 SQL Data Control Language
Chapter 1: Teradata Database Privileges
Automatically Granted Privileges
Automatically Granted Privileges
Automatic privileges fall into two loosely related categories:
•
The set of privileges automatically granted on a database object to the creator of that object.
•
The set of privileges automatically granted to a user or database when that user or database is created.
Automatic privileges are inserted into DBC.AccessRights by the CREATE statement that defines the database object.
Once granted, automatic privileges are identical in form and behavior to explicitly granted privileges.
SQL Data Control Language 25
Chapter 1: Teradata Database Privileges
Inherited Privileges
Inherited Privileges
Users assigned to a role inherit all the privileges granted to that role.
Inherited privileges are a subclass of explicit privileges because a set of privileges is granted explicitly to each role after it is created (see
for an explanation of how privileges are assigned to roles).
Because they are explicit privileges, inherited privilege rows are stored in DBC.AccessRights the same as any other explicit privilege. The only difference is that they are associated with a role rather than a database or user.
Inherited privileges can be revoked in several ways, and at any time, in the ways listed in the following bullets:
•
By explicitly revoking the privilege from a role by means of the REVOKE statement (see
•
By revoking the role assigned to a user (see
“REVOKE (Role Form)” on page 104
).
This action removes specified users from membership in a role, thereby indirectly revoking the privileges they inherited from that membership.
Another way to specify inherited privileges is by means of the TO PUBLIC option (see
“PUBLIC Privileges” on page 27
) for the Monitor and SQL forms of the GRANT statement
(see “GRANT (Monitor Form)” on page 34
and
).
When you specify that a privilege is to be granted TO PUBLIC, that privilege is immediately inherited by all Teradata Database users on the specified object. Granting a privilege TO
PUBLIC also specifies that all future Teradata Database users are to inherit that privilege on the specified object until a REVOKE … TO PUBLIC request on that privilege is submitted.
26 SQL Data Control Language
Chapter 1: Teradata Database Privileges
PUBLIC Privileges
PUBLIC Privileges
When you grant a privilege TO PUBLIC, that privilege is inherited by every valid user of your system. Furthermore, the specified privilege is inherited by all future users of your system unless you issue a REVOKE … FROM PUBLIC statement withdrawing the privilege.
4
To promote optimum system responsiveness, Teradata recommends that you not use the TO object ALL option unless absolutely necessary. This is because the system inserts a row into
DBC.AccessRights for every user that has the privilege.
5
As the size of the DBC.AccessRights table increases, the ability of users to access objects quickly decreases because of the number of rows that must be scanned to locate a privilege for a given user.
As a general rule, you should consider granting privileges at the highest level possible in order to keep the cardinality of DBC.AccessRights at a reasonable level. For example, it is often more performant to grant privileges at the database or user level instead of granting them at the level of objects contained within a database or user.
4. The effect of issuing a REVOKE ALL ON
…
FROM DBC request is not equivalent to the effect of issuing a REVOKE ALL ON
…
FROM PUBLIC request.
The REVOKE ALL ON
…
FROM DBC form stops future users from implicitly receiving privileges on the specified object set, but does not revoke those privileges from existing users to whom the privileges were previously granted by means of a GRANT ALL ON
…
TO PUBLIC statement.
To revoke previously granted implicit privileges, you must submit a REVOKE ALL ON
…
FROM
PUBLIC statement.
5. This means that a row is inserted into DBC.AccessRights for each owner of a privilege, not that a row is inserted for each defined user.
SQL Data Control Language 27
Chapter 1: Teradata Database Privileges
Summary of Implicit, Automatic, Explicit, and Inherited Privilege Types
Summary of Implicit, Automatic, Explicit, and
Inherited Privilege Types
The following table summarizes this information:
How Granted
Implicitly
Automatically
Explicitly
Inherited
Stored in This Table
Not recorded a
DBC.AccessRights
DBC.AccessRights
•
DBC.AccessRights
•
DBC.RoleGrants
No
Yes
Yes
Yes b c
Revokable?
Granted To This Type of
Object
Owner.
d
Creator e
and created database or user.
User or database.
User through a role or
PUBLIC.
a. See
“Summary of Implicit and Explicit Privileges” on page 24 .
b. Implicit privileges cannot be revoked, but they can be given away.
c. Privileges inherited by means of a role can be revoked either by removing the role from a user or by revoking the privilege from a role.
d. An owner can be either a database or a user.
e. A creator is always a user.
28 SQL Data Control Language
CHAPTER 2
SQL Data Control Language
Statement Syntax
This chapter describes the syntax of, and usage information for, the SQL Data Control
Language statements that you can use to grant and revoke the privileges supported by
Teradata Database.
SQL Data Control Language 29
Chapter 2: SQL Data Control Language Statement Syntax
GIVE
GIVE
Purpose
Transfers ownership of a database or user space to another user. Also transfers all databases and users owned by the transferred database or user.
Syntax
GIVE database_name user_name
TO recipient_name
;
FF07A025 where:
Syntax Element...
Specifies...
the name of the database or user whose ownership is being transferred.
database_name user_name
TO
recipient_name
an introduction to the name of the recipient. the name of the new immediate owner for the transferred database or user.
ANSI Compliance
GIVE is an extension to the ANSI SQL:2008 standard.
Required Privileges
You must have the DROP DATABASE privilege on the given object, and the CREATE
DATABASE privilege on the recipient.
The GIVE statement does not revoke any explicit privileges on the given database or user. No explicit privileges on the given database or user are granted to the new ownership hierarchy as a result of the GIVE statement, nor does the database or user being given receive any explicit privileges.
The recipient of a GIVE statement cannot be owned by the given object; if A owns B, A cannot be given to B.
30 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GIVE
Transfer of Space Allocation
A transfer of ownership also transfers the permanent space allocated to the named database or user. This affects space allocation in the system as follows:
•
The aggregate number of permanent space bytes available to the former owners (the owner who submits the GIVE statement plus the owners above this owner in the hierarchy) is reduced by the number of permanent space bytes in the transferred database.
This includes total space allocated to the database, plus that of all databases and users owned by the transferred database.
•
If the transferred database is dropped, then the number of bytes of permanent space allocated to the new immediate owner of the transferred database is increased by the number of bytes of permanent space in the transferred database. In addition, the aggregate number of bytes of permanent space available to owners above this owner in the hierarchy is increased by the number of bytes of permanent space that had been allocated to the transferred database.
For example, consider the following hierarchy:
DBC
A (60)
C (40)
B (80)
D (30)
F (10)
FF07A070
If ownership of database C is transferred to database D, the structure of the hierarchy changes as follows:
A (60)
DBC
B (80)
D (30)
C (40)
F (10)
FF07A071
SQL Data Control Language 31
Chapter 2: SQL Data Control Language Statement Syntax
GIVE
When database C is transferred, database F (which is owned by C) is also transferred.
•
While the number of permanent space bytes allocated to database A remains the same, the aggregate number of permanent space bytes available to database A is reduced by 50 (the total number of permanent space bytes allocated to databases C and F).
•
The number of bytes allocated to databases D and B remains the same.
•
The available number of permanent space bytes, however, is increased by 50 (that is, if databases C and F were dropped, the bytes allocated to C and F are transferred to database
D).
•
A no longer has implicit privileges on C and F.
•
B and D now have implicit privileges on C and F.
•
There is a change in the explicit privileges held by any of the databases or users.
For example, if A had granted itself explicit privileges on C, or F, or on objects they contain, then D would still have those explicit privileges after you had successfully submitted the GIVE statement.
Example
The following statement transfers ownership of the finance database from user administrator to user Chin.
GIVE Finance TO Chin;
32 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT
GRANT
GRANT establishes explicit privileges for one or more users, proxy users, databases, or roles.
GRANT has five forms that differ both in function and in syntax:
•
“GRANT (Monitor Form)” on page 34
, for performance monitoring of Teradata Database.
•
“GRANT (Role Form)” on page 38
, for granting role membership to users and other roles.
•
“GRANT (SQL Form)” on page 41 , for granting access to, creation of, or logging of, various
Teradata database objects.
•
“GRANT CONNECT THROUGH” on page 83 , for granting the ability to connect as a proxy
permanent or proxy application user through a trusted user.
•
, for granting system-wide performance monitoring privileges.
The SQL and MONITOR forms of GRANT are separate statements.
To grant a user all privileges including MONITOR, you must perform both of the following requests:
GRANT ALL PRIVILEGES ON object
TO user
WITH GRANT OPTION;
GRANT MONITOR PRIVILEGES
TO user
WITH GRANT OPTION;
Note that GRANT MONITOR has no ON object clause. Because this statement allows its users to impact the entire system, it implies that the privilege is ON PUBLIC.
SQL Data Control Language 33
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Monitor Form)
GRANT (Monitor Form)
Purpose
Syntax
Grants system-wide performance monitoring privileges.
GRANT
A
MONITOR
,
user_name
ALL
PUBLIC
PRIVILEGES
BUT NOT
,
monitor_privilege
,
monitor_privilege
WITH GRANT
OPTION where:
TO A
;
FF07A056
Syntax Element … Specifies …
MONITOR PRIVILEGES the named recipients are to receive all MONITOR-related privileges.
MONITOR [PRIVILEGES] does not permit the user to grant the indicated privilege to others without the WITH GRANT OPTION being specified.
MONITOR BUT NOT the named recipients are to receive all of the grantable privileges except those specified after BUT NOT.
If the ability to grant these privileges is to be included, the WITH
GRANT OPTION must be specified explicitly.
monitor_privilege
one of the following monitor privileges:
Option Description
ABORTSESSION Aborts any outstanding request or ongoing transaction of one or more Teradata Database sessions and, optionally, logs off the sessions.
MONRESOURCE Gathers information on the performance and availability of each PE and AMP.
34 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Monitor Form)
Syntax Element … Specifies …
Option
MONSESSION
SETRESRATE
SETSESSRATE
Description
Gathers information about logged on sessions and overall system usage on a session-by-session basis.
Sets the frequency at which processor resource usage data is updated in the system.
Sets the frequency at which session-level performance data is updated in the system.
ALL
user_name
PUBLIC to grant the specified object privilege set to the named database or user and to every database or user owned by that database or user now and in the future.
the name of a user or database to be granted the specified MONITOR privileges.
user_name must be the identifier of a user already defined to the system.
You can specify up to 25 names.
that the privileges are to be inherited by all existing and future Teradata
Database users.
WITH GRANT OPTION that the grantee receives privileges WITH GRANT OPTION.
If this option is not specified, the grantee receives the privilege set without the grant option.
ANSI Compliance
The monitor form of GRANT is an extension to the ANSI SQL:2008 standard.
Required Privileges
You must have MONITOR privileges to use the monitor form of GRANT.
Be very selective about granting MONITOR privileges. These privileges should be granted only to those users who are cleared to monitor all applications on all sessions.
There is no lower level of MONITOR privilege: its scope is always global. For example, the database administrator cannot grant user Addams the ability to do session-level monitoring of her applications only. Instead, the DBA would have to grant Addams the permission to do session-level monitoring of all applications by all sessions.
SQL Data Control Language 35
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Monitor Form)
To determine who is currently using the MONITOR partition, issue the following query:
SELECT UserName, IFPNo
FROM DBC.SessionInfoV
WHERE partition = ’MONITOR’;
The GRANT statement is used only to assign specific privileges. To transfer ownership of a
database or user, see “GIVE” on page 30
.
GRANT (SQL Form) and GRANT (MONITOR Form)
The SQL and MONITOR forms of GRANT are separate statements. To grant a user all privileges, including MONITOR, the grantor must perform both statements, as in the following example.
GRANT ALL PRIVILEGES ON object
TO user_name
WITH GRANT OPTION;
GRANT MONITOR PRIVILEGES
TO user_name
WITH GRANT OPTION;
Never specify the WITH GRANT OPTION unless you want the recipient of a privilege to be able to grant it to others.
ALL PRIVILEGES refers only to database-related privileges. MONITOR PRIVILEGES indicates all monitoring-related privileges.
GRANT (SQL Form) Versus GRANT (MONITOR Form)
A major difference between the syntax of the GRANT (SQL Form) and GRANT (MONITOR
Form) statements is that GRANT (MONITOR Form) has no clause that specifies what the privilege has been granted on. Because GRANT (MONITOR form) allows a user to impact the entire system, the permissions are implicitly ON PUBLIC.
It is illegal to specify an ON object clause in any GRANT (MONITOR form) request. However, it is illegal not to specify an ON object clause in a GRANT (SQL Form) request. If you violate either of these restrictions, the system returns a failure response to the requestor.
The two sets of GRANT privileges differ in function as well as in syntax. The GRANT (SQL
Form) privilege set relates to controlling access to, and manipulation of, database objects, while the GRANT (MONITOR form) privilege set relates to monitoring system-wide performance.
36 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Monitor Form)
Privileges Granted Immediately
GRANT MONITOR takes effect immediately when the grantee issues his next statement. It is unnecessary to log out to receive the monitor privilege just granted.
Security Logging of Access Attempts
If you need to maintain a security log of access attempts, see “BEGIN LOGGING” in SQL
Data Definition Language.
Related Topics
See
“REVOKE (Monitor Form)” on page 100
for information about revoking privileges granted by the Monitor form of GRANT.
SQL Data Control Language 37
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Role Form)
GRANT (Role Form)
Purpose
Grants roles to users or other roles.
Syntax
GRANT
, role_name TO
, user_name role_name
WITH ADMIN OPTION
;
KZ01a008 where:
Syntax Element …
role_name
Specifies …
one or more comma-separated names of roles to grant to specified users or other roles.
The system ignores duplicate role names.
TO
user_name role_name
the names of role grantees.
You can specify a maximum of 25 names per GRANT request.
Grantees can be users or roles; however, a role cannot be granted to itself or to PUBLIC.
GRANT does not produce an error if a specified role is already granted to a grantee.
WITH ADMIN OPTION that the role grantees have the privilege to use DROP ROLE, GRANT, and REVOKE statements to administer the specified roles.
A GRANT statement that does not include WITH ADMIN OPTION does not revoke a previously granted WITH ADMIN OPTION privilege from grantee.
ANSI Compliance
GRANT is ANSI SQL:2008-compliant.
38 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Role Form)
Required Privileges
To grant a role, you must have the WITH ADMIN OPTION privilege on the role. The following users can grant a role to a user or other role:
•
User DBC.
•
A user who has been granted the specified role WITH ADMIN OPTION.
The creator of a role is automatically granted the specified role WITH ADMIN OPTION.
•
A user who has an active role to which the specified role was granted WITH ADMIN
OPTION. An active role can be a current role or a nested role of a current role.
A grantor does not need to have any privilege, including WITH ADMIN OPTION, on the grantee to grant a privilege to it, whether the grantee is a role or a user.
Restricted Privileges
Roles cannot be granted on themselves or on PUBLIC, nor can they be granted any of the following privileges:
•
CREATE PROFILE
•
CREATE ROLE
•
CREATE USER
•
CTCONTROL
•
DROP PROFILE
•
DROP ROLE
•
DROP USER
•
REPLCONTROL
About Roles
Roles define privileges on database objects. A user who is assigned a role can access all the objects on which the role and its nested roles have privileges. Users can only be assigned a role that has been granted to them.
You can grant a newly created role to a user or other role before the role has privileges on any database objects.
An unlimited number of roles can be granted to a role or user.
Role Hierarchy
Roles can only be nested one level deep. Thus, a role that has a nested role cannot also be a nested role.
This is a deviation from the ANSI SQL:2008 standard, which allows multiple nesting levels.
SQL Data Control Language 39
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (Role Form)
Example
The following statements create roles called services and sales:
CREATE ROLE services;
CREATE ROLE sales;
To make sales a nested role of services, use the following GRANT statement:
GRANT sales TO services;
To grant the sales role to user marks, and give marks the privilege to add other members to sales, use the following GRANT statement:
GRANT sales TO marks WITH ADMIN OPTION;
Related Topics
See
“REVOKE (Role Form)” on page 104
for information about revoking privileges granted by the Role form of GRANT.
FOR more information on …
granting privileges on database objects to roles obtaining the CREATE ROLE system privilege granting CONNECT THROUGH proxy connection privileges to a permanent or application user with a set of roles assigning default roles to users changing the current role for a session
SEE …
.
“GRANT CONNECT THROUGH” on page 83
•
“CREATE USER” in SQL Data Definition
Language.
•
“MODIFY USER” in SQL Data Definition
Language.
“SET ROLE” in SQL Data Definition Language.
40 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
GRANT (SQL Form)
Purpose
Assigns one or more explicit privileges on a database, user, proxy logon user, table, hash index, join index, view, stored procedure, user-defined function, user-defined method, user-defined type, or macro to a role, group of roles, user, or group of users or databases.
Syntax
GRANT ALL
PRIVILEGES
,
privilege
,
ALL BUT
privilege
ON
B TO
A
database_name user_name role_name
PUBLIC
database_name.
user_name.
object_name object_name procedure_name
PROCEDURE
TYPE
,
role_privilege
,
profile_privilege
SYSUDTLIB.
database_name.
user_name.
SPECIFIC FUNCTION
FUNCTION
specific_function_name database_name.
user_name.
function_name
(
database_name.
user_name.
parameter_name
,
UDT_name
,
user_name
25
ALL
PUBLIC
WITH GRANT OPTION
;
,
role_name database_name.
user_name.
data type
)
A
B
1101W055
SQL Data Control Language 41
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
A
Data Type
INTEGER
SMALLINT
BIGINT
BYTEINT
DATE
TIME
TIMESTAMP
( fractional_seconds_precision ) WITH TIMEZONE
INTERVAL YEAR
( precision ) TO MONTH
INTERVAL MONTH
( precision )
INTERVAL DAY
( precision )
TO HOUR
MINUTE
SECOND
( fractional_seconds_precision
)
INTERVAL HOUR
( precision
)
TO MINUTE
SECOND
( fractional_seconds_precision )
INTERVAL MINUTE
( precision )
TO SECOND
(
fractional_seconds_precision
)
INTERVAL SECOND
( precision
, fractional_seconds_precision
PERIOD(DATE)
PERIOD(TIME
PERIOD(TIMESTAMP ( precision ) WITH TIMEZONE
REAL
DOUBLE PRECISION
FLOAT
( integer )
DECIMAL
NUMERIC ( integer )
, integer
)
)
B
1101A535
42 SQL Data Control Language
A
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
B
CHAR
BYTE
GRAPHIC
VARCHAR
CHAR VARYING
VARBYTE
VARGRAPHIC
LONG VARCHAR
LONG VARGRAPHIC
( integer )
( integer )
BINARY LARGE OBJECT
BLOB
CHARACTER LARGE OBJECT
CLOB
(
integer
SYSUDTLIB.
UDT_name
ST_Geometry
MBR
G
K
M where:
Syntax Element …
ALL [PRIVILEGES]
privilege
(
1101A536
Specifies …
that the specified user, database, or role is to receive all privileges that can be granted on the specified object.
To include the ability for the designated user to GRANT object privileges to other users or databases, use the WITH GRANT OPTION clause.
GRANT ALL means that all implicit and explicit object privileges owned by the grantor WITH GRANT OPTION that pertain to the type of object, and only those privileges, are granted on the specified database object.
An error is returned if the grantor has no privileges WITH GRANT
OPTION on the object.
You must use the monitor form of the GRANT statement to grant monitor
privileges. See “GRANT (Monitor Form)” on page 34
.
one of the privileges listed under the topic “ANSI Compliance” on page 30
.
SQL Data Control Language 43
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Syntax Element … Specifies …
OR specify this keyword …
AUTHORIZATION
DATABASE
TO grant these privileges …
•
CREATE AUTHORIZATION
•
DROP AUTHORIZATION
•
CREATE DATABASE
•
DROP DATABASE
DROP
IF the ON clause specifies …
FUNCTION
PROCEDURE
THEN the privilege granted is …
DROP
FUNCTION
DROP
PROCEDURE
EXECUTE
FUNCTION
GLOP
MACRO
PROCEDURE
TABLE
TRIGGER
IF the ON clause specifies …
FUNCTION
PROCEDURE nothing
THEN the privilege granted is …
EXECUTE
FUNCTION
EXECUTE
PROCEDURE
EXECUTE
MACRO
•
CREATE FUNCTION
•
DROP FUNCTION
•
CREATE GLOP
•
DROP GLOP
•
CREATE MACRO
•
DROP MACRO
•
CREATE PROCEDURE
•
DROP PROCEDURE
•
CREATE TABLE
•
DROP TABLE
•
CREATE TRIGGER
•
DROP TRIGGER
44 SQL Data Control Language
Syntax Element …
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Specifies …
OR specify this keyword …
USER
VIEW
TO grant these privileges …
•
CREATE USER
•
DROP USER
•
CREATE VIEW
•
DROP VIEW
Note that the INSERT, REFERENCES, SELECT, and UPDATE privileges
have both table- and column-level options. See “REFERENCES” on page 56
.
The DELETE privilege applies only to the DELETE DML statement, not to
DELETE USER or DELETE DATABASE, which are granted by DROP
USER and DROP DATABASE, respectively.
See also “Rules for privilege Keywords” on page 53 . However, for a full
explanation of the privileges a specific statement requires, see its
Authorization section in the appropriate volume of the SQL book set.
With the exception of the following items, the privileges do not directly correspond to an SQL statement:
THIS privilege …
CHECKPOINT
DUMP
EXECUTE FUNCTION
EXECUTE PROCEDURE
INDEX
REFERENCES
RESTORE
REFERS to …
both to the execution of the SQL statement and the Host Utilities (HUT) commands DUMP and RESTORE.
the corresponding HUT command performed on the specified object.
a UDF function call.
the corresponding CALL statement.
the CREATE and DROP INDEX and
COLLECT and DROP STATISTICS statements.
columns referenced in a FOREIGN KEY clause of a CREATE or ALTER TABLE statement.
the corresponding HUT command performed on the specified object and to the execution of the following additional
HUT commands:
•
DELETE JOURNAL
•
ROLLBACK
•
ROLLFORWARD
SQL Data Control Language 45
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
46
Syntax Element …
profile_privilege role_privilege
ALL BUT
database_name |
user_name | role_name |
PUBLIC
[PROCEDURE]
[database_name |
user_name]
procedure_name
Specifies …
one of the following profile privileges:
•
CREATE PROFILE
•
DROP PROFILE
•
PROFILE
PROFILE is not a separate privilege. It is a shorthand way to specify both CREATE PROFILE and DROP PROFILE.
Profile privileges can only be granted to a set of users or to a role. They cannot be granted on an object.
Specify PROFILE to grant the CREATE PROFILE and DROP PROFILE privileges.
one of the following role privileges:
•
CREATE ROLE
•
DROP ROLE
•
ROLE
ROLE is not a separate privilege. It is a shorthand way to specify both
CREATE ROLE and DROP ROLE.
Role privileges cannot be granted to a role or to PUBLIC.
Specify ROLE to grant the CREATE ROLE and DROP ROLE privileges.
the named user is to receive all privileges that can be granted on the specified object except for those specified in the privilege list. As in ALL, only those object privileges owned by the grantor WITH GRANT
OPTION are granted.
ALL BUT is a Teradata extension to the ANSI SQL:2008 standard.
Granting privileges on a database or user is a Teradata extension to the
ANSI SQL:2008 standard.
the name of a database, user, role or PUBLIC on which the explicitly granted privileges are to be granted. All objects contained by this database or user space are affected.
that the object is a stored procedure.
PROCEDURE is optional if the privilege being granted contains the
PROCEDURE keyword. See “Stored Procedure-SpecificPrivileges” on page 68
.
You can qualify procedure_name by its containing database_name or
user_name if necessary.
IF you specify PROCEDURE, you can specify …
EXECUTE
DROP
AS privilege to grant this privilege …
EXECUTE PROCEDURE.
DROP PROCEDURE.
You must grant the ALTER EXTERNAL PROCEDURE and CREATE
EXTERNAL PROCEDURE privileges explicitly.
SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Syntax Element …
SPECIFIC FUNCTION
[database_name |
user_name]
specific_function_name
FUNCTION
[database_name |
user_name]
function_name
[parameter_name]
data_type
TYPE [SYSUDTLIB.]
UDT_name
Specifies …
the specific name of the function on which a privilege set is to be granted.
The SPECIFIC FUNCTION keywords must be specified when a privilege is granted on an overloaded function.
You can qualify specific_function_name by its containing database_name or
user_name if necessary.
the name of the function on which a privilege set is to be granted.
FUNCTION is optional if the privilege being granted contains the
FUNCTION keyword.
The FUNCTION keyword must be specified when a privilege is granted on a function by its calling name.
You can qualify function_name by its containing database_name or
user_name if necessary.
a parenthetical comma-separated list of data types and optional parameter names for the variables to be passed to the function. The data types are required to discriminate among overloaded functions that have the same name.
BLOB and CLOB types must be represented by a locator (see “USING
Request Modifier” in SQL Data Manipulation Language for a description of locators). Teradata Database does not support in-memory LOB parameters: an AS LOCATOR phrase must be specified for each LOB parameter and return value.
You must specify opening and closing parentheses even if no parameters are passed to the function.
If you specify one parameter name, then you must specify names for all the parameters passed to the function (see “HELP FUNCTION” in SQL Data
Definition Language).
The data type associated with each parameter is the type of the parameter or returned value. All Teradata Database data types are valid. Character data can also specify a CHARACTER SET clause.
the name of a UDT on which a privilege set is to be granted.
The various TYPE privileges can be granted as follows:
database_name |
user_name
THIS privilege …
UDTMETHOD
UDTTYPE
UDTUSAGE
CAN be granted on …
SYSUDTLIB database.
•
SYSUDTLIB database.
•
TYPE.
the name of a database or user on which the privileges are to be granted.
All objects in this database or user space are affected.
SQL Data Control Language 47
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Syntax Element …
database_name.
object_name |
user_name.object_name
object_name
Specifies …
the name of the immediately owning database or user and the name of the object (table, view, stored procedure, or macro) on which the privileges are to be granted. Only the named object is affected. the name of the object (table, view, join index, function, stored procedure, or macro) on which the privileges are to be granted.
You should always qualify object names when granting privileges because the system checks for matching database names before checking for object names.
[ALL] user_name
PUBLIC
WITH GRANT
OPTION
database_name |
user_name role_name
IF …
the object name is not qualified and the system finds a database with that name the object name is not qualified and no database having that name is found neither a database nor an object is found
THEN the system …
assumes it is a database name.
assumes it is an object within the current default database.
returns an error to the requestor.
the name of a database or user that identifies the recipient. user_name must be the identifier of a user already defined to the system.
You can specify a maximum of 25 names per GRANT request.
If you specify ALL, then the object privileges are granted to the named database or user and to every database or user owned by that database or user now and in the future.
ALL is a Teradata extension to the ANSI SQL:2008 standard.
that the privileges are inherited by all existing and future Teradata
Database users and databases. that the grantee receives the granted privileges WITH GRANT OPTION.
This option does not apply to grantees that are roles. A GRANT statement that specifies WITH GRANT OPTION when there is a role in the list of grantees aborts and returns an error message.
the containing database or user for role_name, if something different from the current database or user.
the name of a role.
The role must already be defined to the system.
The CREATE forms of DATABASE, FUNCTION, MACRO, TABLE, VIEW,
PROCEDURE, or USER, and the DROP forms of DATABASE and USER are allowed only on databases or users.
You cannot grant any of these privileges to roles.
48 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Syntax Element …
REPLCONTROL
Specifies …
the REPLCONTROL privilege.
REPLCONTROL control two separate functions:
•
The privilege to define and manage replication groups.
•
The ability to run SQL statements that change columnar data values for a table when that table is in a state that would not otherwise allow changes to be made.
ANSI Compliance
The SQL form of GRANT is ANSI SQL:2008-compliant with extensions.
ANSI SQL:2008 supports the following privileges in common with Teradata SQL:
•
DELETE
•
EXECUTE
•
INSERT [(column_list)]
•
REFERENCES [(column_list)]
•
SELECT [(column_list)]
•
TRIGGER
• UPDATE [(column_list)]
The term [(column_list)] following a privilege indicates a parenthetically enclosed set of optional comma-separated column names to which the privilege is to be granted.
The privileges in the following list are Teradata extensions to the privileges defined in the
ANSI SQL:2008 standard:
SQL Data Control Language 49
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
•
ABORT SESSION
•
ALTER EXTERNAL
PROCEDURE
•
ALTER FUNCTION
•
ALTER PROCEDURE
•
AUTHORIZATION
•
CHECKPOINT
•
CREATE
AUTHORIZATION
•
CREATE DATABASE
•
CREATE EXTERNAL
PROCEDURE
•
CREATE FUNCTION
•
CREATE GLOP
•
CREATE MACRO
•
CREATE OWNER
PROCEDURE
•
CREATE PROCEDURE
•
CREATE PROFILE
•
CREATE ROLE
•
CREATE TABLE
•
CREATE TRIGGER
•
CREATE USER
•
CREATE VIEW
•
CTCONTROL
•
DATABASE
•
DROP
•
DROP AUTHORIZATION
•
DROP DATABASE
•
DROP FUNCTION
•
DROP GLOP
•
DROP MACRO
•
DROP PROCEDURE
•
DROP PROFILE
•
DROP ROLE
•
DROP TABLE
•
DROP TRIGGER
•
DROP USER
•
DROP VIEW
•
DUMP
•
EXECUTE FUNCTION
•
EXECUTE PROCEDURE
•
FUNCTION
•
GLOP
•
GLOP MEMBER
•
INDEX
•
MACRO
•
MONITOR RESOURCE
•
MONITOR SESSION
•
PROCEDURE
•
REFERENCES ALL BUT …
[(column_list)]
•
REPLCONTROL
•
RESTORE
•
SET RESOURCE RATE
•
SET SESSION RATE
•
SHOW
•
STATISTICS
•
TABLE
•
UDTMETHOD
•
UDTTYPE
•
UDTUSAGE
•
UPDATE ALL BUT …
[(column_list)]
•
USER
•
VIEW
The following privileges are defined in the ANSI SQL:2008 standard, but are not valid in
Teradata SQL:
•
SELECT [(privilege_method_list)]
•
UNDER
•
USAGE
Required Privileges
You must be one of the following to grant privileges on an object using the SQL GRANT statement:
•
User DBC.
•
An owner of the object.
There is a subtle security issue associated with this. See
CREATE MACRO Privilege” on page 57 for details.
•
A user possessing each privilege to be granted.
A user might have a privilege either by having been granted it explicitly or by inheriting it from a role as a result of creating a view, macro, or stored procedure.
50 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Note the following details:
•
A user need not be related to a grantor through ownership to receive a privilege.
A grantor does not need to have any privilege, including WITH ADMIN OPTION, on the grantee to grant a privilege to it, whether the grantee is a role, a user, database, or PUBLIC.
•
If a GRANT statement is on a database or user, the privilege applies to all objects, both current and future, created in that space.
If a REVOKE statement later removes the privilege, the privilege is dropped for all objects, regardless of when they were created.
A REVOKE statement at the object level cannot remove a privilege from that object that was granted on the database or user.
•
When you specify the WITH GRANT OPTION phrase, the recipient of the privilege can then grant that privilege to other users.
An owner implicitly has the WITH GRANT OPTION privilege on any database, user, or object it owns.
An owner can explicitly grant any or all privileges on any of the following …
•
a child database
•
a child user
•
a database object
TO …
•
any other database
•
any other user
•
a role
•
PUBLIC
•
Any privilege granted automatically or explicitly
1
can be revoked using the REVOKE statement. See
“REVOKE (SQL Form)” on page 107 .
•
Implicit privileges cannot be revoked.
Multiple Privileges Specified by a Single Keyword
Teradata Database has a special category of keywords that you can use to grant multiple privileges. For example, the following GRANT request grants both the CREATE DATABASE and DROP DATABASE privileges to user df2 using the keyword DATABASE:
GRANT DATABASE on df2;
The following table lists this class of keywords and indicates the multiple privileges that they confer when they are granted on a user or database:
The following keyword … Indicates the following privileges …
ALL all implicit and explicit object privileges owned by the grantor WITH
GRANT OPTION that pertain to the type of object specified, and only those privileges, are granted on the specified database object.
1. That is, any explicit privilege.
SQL Data Control Language 51
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
The following keyword … Indicates the following privileges …
CHECKPOINT
•
ability to execute the CHECKPOINT SQL statement.
•
ability to execute the HUT CHECKPOINT command.
DATABASE
FUNCTION
•
CREATE DATABASE
•
DROP DATABASE
•
CREATE FUNCTION
•
DROP FUNCTION
GLOP
INDEX
•
CREATE GLOP
•
DROP GLOP
•
COLLECT STATISTICS
•
CREATE INDEX
•
DROP INDEX
•
DROP STATISTICS
MACRO
PROCEDURE
PROFILE
RESTORE
ROLE
SHOW
•
CREATE MACRO
•
DROP MACRO
•
CREATE PROCEDURE
•
DROP PROCEDURE
•
CREATE PROFILE
•
DROP PROFILE ability to execute the following HUT commands on the specified object:
•
DELETE JOURNAL
•
ROLLBACK
•
ROLLFORWARD
•
CREATE ROLE
•
DROP ROLE the ability to execute the following SQL statements only:
•
HELP database_object
•
SHOW database_object
TABLE
TRIGGER
USER
VIEW
•
CREATE TABLE
•
DROP TABLE
•
CREATE TRIGGER
•
DROP TRIGGER
•
CREATE USER
•
DROP USER
•
CREATE VIEW
•
DROP VIEW
52 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Privilege Abbreviations
See Data Dictionary for a complete list of privileges and their abbreviations as maintained in
DBC.AccessRights. You cannot use these abbreviations in a GRANT (SQL Form) request.
Instead, you must specify the complete privilege name.
Rules for privilege Keywords
The following rules apply to using the privilege keywords.
•
You can specify any combination of privileges. However, the user submitting the statement must have privileges on all of the specified privileges for the system to grant them.
•
The recipient of a privilege can perform the corresponding statement against the object on which the privilege was granted.
For example, if user_1 receives the CREATE TABLE privilege on database DbTest, user_1 can then perform a CREATE TABLE statement in which the new table is directed to
DBTest, where the target database is resolved either implicitly, as determined by the default database for user1, or explicitly with a fully qualified table name.
•
The CHECKPOINT privilege refers to the execution of both the SQL statement and the
Host Utilities (HUT) command.
The DUMP and RESTORE privileges refer to the corresponding HUT command performed on the specified object.
RESTORE also refers to execution of the HUT commands ROLLBACK, ROLLFORWARD, and DELETE JOURNAL.
•
The CREATE forms of DATABASE, FUNCTION, MACRO, TABLE, VIEW, PROCEDURE, or USER, and the DROP forms of DATABASE and USER are allowed only on databases or users.
•
DROP TABLE authorizes the following statements on the tables:
•
ALTER TABLE
•
COLLECT STATISTICS
•
CREATE INDEX
•
DROP INDEX
• DROP STATISTICS
•
DROP MACRO, PROCEDURE, or VIEW includes REPLACE MACRO, PROCEDURE, or
VIEW.
•
Only DROP MACRO and EXECUTE are allowed on macros.
•
Only ALTER PROCEDURE, DROP PROCEDURE, EXECUTE PROCEDURE, and
CREATE OWNER PROCEDURE are allowed on stored procedures.
•
CREATE OWNER PROCEDURE is an explicit privilege that must be granted explicitly to a user or database.
Because it is the responsibility of each site to control its own security, the DBA or Security
Administrator should take the appropriate actions to prevent the CREATE OWNER
PROCEDURE privilege from being granted indiscriminately.
•
ALTER EXTERNAL PROCEDURE is required to change the execution state of an external procedure between the PROTECTED and NOT PROTECTED states using the ALTER
PROCEDURE (External Form) statement (see SQL Data Definition Language).
SQL Data Control Language 53
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
•
Only ALTER FUNCTION, DROP FUNCTION, and EXECUTE FUNCTION are allowed on user-defined functions.
•
DUMP, RESTORE, INDEX, and CHECKPOINT are not allowed on views.
•
DATABASE, FUNCTION, INDEX, GLOP, MACRO, PROCEDURE, PROFILE, ROLE,
TABLE, USER, and VIEW confer both CREATE and DROP privileges.
If the DATABASE, FUNCTION, INDEX, GLOP, MACRO, PROCEDURE, PROFILE,
ROLE, TABLE, USER, or VIEW keyword is specified without CREATE or DROP, both
CREATE and DROP are assumed by default.
•
INDEX authorizes the following statements on the tables:
•
COLLECT STATISTICS
•
CREATE INDEX
•
DROP INDEX
•
DROP STATISTICS
If INDEX is granted on all of the base tables of a join index, INDEX also allows COLLECT and DROP STATISTICS on the join index.
•
INSERT, REFERENCES, SELECT, and UPDATE have both table- and column-level options.
•
You cannot grant the UPDATE privilege on a GENERATED BY DEFAULT identity column.
•
You cannot grant privileges on a trigger, only on the database or table to which the trigger applies.
The CREATE TRIGGER and DROP TRIGGER privileges are granted to a user, either on the specified database or on the subject table of the trigger.
•
You can grant CREATE ROLE, DROP ROLE, CREATE PROFILE, and DROP PROFILE privileges to users only, not to roles, databases, or PUBLIC.
•
CREATE ROLE, DROP ROLE, CREATE PROFILE, and DROP PROFILE are system privileges; you grant the privileges to a user, but not on a specific object.
•
With respect to collecting or dropping statistics, the STATISTICS privilege has the same effect as either INDEX or DROP TABLE, but does not grant users the wider capabilities associated with those privileges. STATISTICS can be granted at both the table and database levels.
•
You cannot grant external roles with the GRANT statement. You can only grant individual privileges and database roles to external roles within Teradata Database. See Security
Administration and Database Administration for details.
•
A GRANT or REVOKE request for the CTCONTROL and REPLCONTROL system privileges can only be submitted by user DBC or by a user who has previously been granted the privilege WITH GRANT OPTION.
•
The name of the user you specify when you grant the CTCONTROL or REPLCONTROL privilege must be a unique identifier that is assigned to an existing system user. It cannot be the name of a role defined in the system.
Be very careful about granting system privileges like REPLCONTROL, because they apply to all database objects in the system.
54 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
•
When you specify the phrase GRANT OPTION FOR in a REVOKE request, the system removes only the ability of the recipient to grant the privilege to others. The system does
not remove the specified privilege itself when you specify GRANT OPTION FOR in a
REVOKE request.
•
The SHOW privilege enables a user to view the definition (using a SHOW object_type request), or request help about definitions and other information (using a HELP
object_type request) for a database object without also being able to change the definition of the object or retrieve rows from it.
SHOW, which must be granted explicitly, can be granted at the object and database levels.
The creator of an object does not receive the SHOW privilege automatically on the object it creates. User DBC can also grant this privilege on the dictionary tables to other users/ databases.
You can use SHOW to provide access to statements such as SHOW TABLE, HELP TABLE, and HELP STATISTICS that require any privilege of any kind. All statements that require any privilege can also use SHOW.
This privilege provides a DBA with the ability to grant a user the ability to SHOW a table or view, or do HELP STATISTICS, and so on without having SELECT access to a table.
Differences Between GRANT and GIVE
The GRANT statement is used only to assign specific privileges, while the GIVE statement transfers the ownership of a database or user to another database or user. See
for details.
Privileges Are Granted Immediately
GRANT takes effect immediately when the grantee issues their next statement. You do not need to log out to receive a privilege that was just granted to you.
Object Names
The element object_name is the name of a table, join index, hash index, view, stored procedure, user-defined function, user-defined method, user-defined data type, or macro. If the form of the privileges option includes a set of column names, then object_name must specify either a table or view.
If object_name is not qualified by either a database name or user name and there is an object having that same name both under the current database of the executing user and that of the grantee, then it is assumed that the object is that in the current database of the executing user.
The only exception to this is for all objects related to UDTs, including UDT-related UDFs and
UDMs, all of which must be contained within the SYSUDTLIB database.
An unqualified object_name is considered to be that of the current database if the name is that of the current database and also the name of a table either within the current database or within the database of the grantee.
SQL Data Control Language 55
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
REFERENCES
The REFERENCES privilege applies at both the table and column levels. It is required on all columns referenced, whether implicitly or explicitly, in a FOREIGN KEY clause of a CREATE
TABLE or ALTER TABLE statement. The system grants this privilege automatically, with grant authority, to the creator of a table. Owners acquire the privilege implicitly.
If you specify a column list (a list of parenthetically enclosed, comma-separated column names, for example
(column_name_1, ..., column_name_n)
) with the keywords
INSERT, REFERENCES, SELECT, or UPDATE, and the specified grantee set already has the privilege specified at the table level with the indicated grant authority, then the system accepts the statement but takes no action. This is because having INSERT, REFERENCES, SELECT, or
UPDATE privileges at table level also enables that action against all of its columns.
INDEX
The INDEX privilege only applies at table level. You must have either this privilege or DROP
TABLE to perform the CREATE or DROP INDEX and COLLECT or DROP STATISTICS statements. The system implicitly gives this privilege, with grant authority, to the immediate owner of the table at the time of creation.
Column-Level Privileges
The DBC.AccessRights table stores the field ID of a column on which an INSERT,
REFERENCES, SELECT, or UPDATE privilege has been granted. The column type is non-null
SMALLINT. If the privilege defined by the row is not at the column level then the value of the column is set to zero.
Column-level privileges are held implicitly by the owners of a table. As is always true for implicit privileges, a row is not inserted into DBC.AccessRights for implicit column-level privileges.
Rows are also not generated in DBC.AccessRights for individual columns when the INSERT,
REFERENCES, SELECT, or UPDATE privileges are granted at the table level.
Rows are generated in DBC.AccessRights only for privileges granted by a GRANT statement at the column level when the grantee does not have the privilege at the table level. The only exception is the case of a user or database that has a privilege at table level but without
GRANT authority and who then is granted the same privilege on an individual column of the same table with grant authority.
Privileges Required to Perform UPDATE, DELETE, and INSERT Operations
Any user who needs to perform any form of update, delete, or insert operations, including the insert and update operations performed by a MERGE request, must be granted the SELECT privilege on all columns that are read by the delete, insert, merge, or update request from which that user needs to read values.
For the INSERT statement, SELECT privileges are required only if a table is to be reflexively grown by INSERT … SELECT statements performed on itself.
56 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
If the column being updated, deleted, or inserted into has a UDT type, then you must also have the UDTUSAGE or UDTTYPE privilege on that UDT.
Be careful when granting the delete privilege through a view because data in columns that are not defined in the view (and which might be important to the enterprise) might unsuspectingly be deleted when an unknowing user deletes a row through a view.
Security Considerations With CREATE MACRO Privilege
Before you grant CREATE MACRO on a database or user, it is extremely important to realize that the recipient of that privilege can create and perform macros that have all the privileges of that database or user. This is because for CREATE MACRO, the privileges are inherited from the immediate owner of the macro, not from its creator.
As a result, the grantee can create macros that contain DCL and DDL statements that are not checked for the privileges of the creator. This means that you are implicitly assigning privileges to the macro creator that they have no explicit, implicit, or automatic privilege to perform.
This might not be a desirable result and you should be exceedingly careful when granting this privilege.
For example, consider the scenario presented in the following graphic.
SysAdmin DBA DBA
GRANT CREATE MACRO
ON Compensation
TO CompAnalyst 6;
CompAnalyst 6 Compensation
CREATE MACRO everything AS
(GRANT ALL PRIVILEGES ON Compensation
TO CompAnalyst 6;);
1101B001
The compensation database is owned by user DBA.
User SysAdminDBA, the system administrator for compensation, has privileges on
compensation, including CREATE MACRO WITH GRANT OPTION, and on all objects owned by compensation.
SysAdminDBA can also effectively grant herself any of the following:
•
Privileges on objects owned by compensation.
•
Privileges that compensation has WITH GRANT OPTION.
•
Any implicit privileges owned by compensation.
SysAdminDBA creates user CompAnalyst6 for an entry level programmer who has been assigned to produce compensation reports for several routine audits performed by various state and federal regulatory agencies. To ensure that CompAnalyst6 does not have access to
SQL Data Control Language 57
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form) critical private employee base salary and bonus information, she has been granted only a restricted set of privileges on objects in the compensation database.
To make it easier for CompAnalyst6 to create the reports, SysAdminDBA also grants her the
CREATE MACRO privilege on compensation as follows:
GRANT CREATE MACRO
ON compensation
TO companalyst6;
Because the privileges for executing macros in compensation derive from compensation,
CompAnalyst6 can create and perform macros that report on just the sort of private data she was meant to be restricted from viewing.
For example, CompAnalyst6 can grant herself full access to all tables in the database through a simple macro and then create any database object or perform a query that reports on salary and bonus data for each employee in the enterprise in the three quick steps outlined in the following procedure:
1 CREATE MACRO everything AS
(GRANT ALL PRIVILEGES ON compensation
TO companalyst6;);
2 EXECUTE MACRO everything;
3 SELECT *
FROM salary, bonus;
4
End of procedure.
CompAnalyst6 is also able to modify data and drop tables in the compensation database.
Logging Access Attempts
If you need to maintain a security log of access attempts, you can use the access logging feature to do so (see “BEGIN LOGGING” in SQL Data Definition Language).
Restrictions on Granted Privileges
When a user explicitly grants privileges to another user, database, role, or PUBLIC, there are rules that determine whether, how, and on what object the requested privilege can be implemented. The restrictions that apply to explicitly granted privileges are detailed in the following table.
The first column of the table lists the privilege type, the second column describes restrictions if the privilege is granted on a database, user, role, or PUBLIC, and the third column describes restrictions if the privilege is granted on a table, view, function, stored procedure, method,
UDT, or macro.
58 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
ALL
Privilege Object (Database, User, Role, PUBLIC)
All privileges the grantor can grant on an object.
•
Grants UDTMETHOD on the SYSUDTLIB database.
If granted WITH GRANT OPTION, permits grantee to grant others UDTMETHOD,
UDTTYPE, and UDTUSAGE, optionally
WITH GRANT OPTION.
Table, View, Function, GLOP, Method, UDT,
Procedure, or Macro
The following are true only if the grantor owns the privilege:
•
Grants EXECUTE and DROP on a macro.
•
Grants DROP, DELETE, INDEX, INSERT,
REFERENCES, SELECT, UPDATE,
RESTORE, CREATE TRIGGER, DROP
TRIGGER, and DUMP on a data table.
•
Grants DROP on hash and join indexes.
•
Grants DROP, DELETE, INSERT,
SELECT, and UPDATE on a view.
•
Grants INSERT, DUMP, RESTORE, and
CHECKPOINT on a journal table.
•
Grants ALTER PROCEDURE, DROP
PROCEDURE, and EXECUTE
PROCEDURE privileges on a stored procedure.
•
Grants ALTER FUNCTION, DROP
FUNCTION, and EXECUTE
FUNCTION privileges on a specified user-defined function.
•
Grants CREATE GLOP, GLOP, and DROP
GLOP to a user.
•
Grants GLOP MEMBER to a specified user or database.
Privilege applies to the specified user-defined functions or internal stored procedures.
Privilege applies to the specified external stored procedure.
Privilege applies to the named journal table.
ALTER FUNCTION
ALTER PROCEDURE
ALTER EXTERNAL
PROCEDURE
CHECKPOINT
Privilege applies to all user-defined functions or internal stored procedures in the specified space.
Privilege applies to all external stored procedures in the specified space.
Privilege applies to the journal table in the specified database.
CREATE granted for the specified space.
CREATE DATABASE
CREATE USER
CREATE EXTERNAL
PROCEDURE
CREATE FUNCTION
CREATE MACRO
CREATE
PROCEDURE
CREATE TABLE
CREATE VIEW
CREATE GLOP
CREATE granted for the object type for the specified space.
Not applicable.
Not applicable.
CREATE granted for the specified user.
This privilege is not granted automatically when a user or database is created.
SQL Data Control Language 59
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Privilege
GLOP MEMBER
CREATE PROFILE
CREATE ROLE
CREATE TRIGGER
CTCONTROL
Object (Database, User, Role, PUBLIC)
Table, View, Function, GLOP, Method, UDT,
Procedure, or Macro
Privilege enables an external routine to access the GLOP set specified in the MEMBER OF GLOP
SET clause of its definition when that GLOP set is not contained within the containing user or database for the routine.
This privilege is not granted automatically when a user or database is created.
CREATE PROFILE and CREATE ROLE cannot be granted on an object.
CREATE granted for the object type for the specified space.
CREATE PROFILE and CREATE ROLE cannot be granted on an object.
CREATE granted for the specified table.
Privilege is granted to or revoked from user objects.
CTCONTROL can only be granted to a user.
User DBC can grant CTCONTROL to any other user WITH GRANT OPTION.
CREATE and DROP granted for the type for the specified space.
Not applicable.
TRIGGER applies to the table on which a trigger is defined.
DATABASE
FUNCTION
GLOP
INDEX
MACRO
PROCEDURE
PROFILE
ROLE
TABLE
TRIGGER
USER
VIEW
DELETE
INSERT
SELECT
UPDATE
DROP
DROP DATABASE
DROP USER
Privilege applies to all tables or views in the specified database.
UPDATE, INSERT, and SELECT apply to a table or column set of the table.
For a grantee to use the granted privileges on a view, the immediate owner of a view must have appropriate privileges on the tables and views referenced by the view.
Not applicable.
DROP granted for the specified space.
Privilege applies only to the specified table, view, or columns.
UPDATE cannot be granted on a
GENERATED ALWAYS identity column.
For a grantee to use the granted privileges on a view, the immediate owner of a view must have appropriate privileges on the tables and views referenced by the view.
DROP granted for specified:
•
Stored procedures when PROCEDURE is specified before the procedure name or for the specified function.
•
Functions when FUNCTION or
SPECIFIC FUNCTION is specified before the function name.
Not applicable.
60 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Privilege
DROP FUNCTION
DROP MACRO
DROP PROCEDURE
DROP TABLE
DROP TRIGGER
DROP VIEW
DROP GLOP
DROP PROFILE
DROP ROLE
DUMP
RESTORE
EXECUTE
EXECUTE
FUNCTION
EXECUTE
PROCEDURE
INDEX
DROP granted for the object type for the specified space.
Object (Database, User, Role, PUBLIC)
Table, View, Function, GLOP, Method, UDT,
Procedure, or Macro
DROP granted for the specified user-defined function, macro, stored procedure, table, or view.
DROP TABLE also grants the privilege to collect statistics on an eligible database object.
DROP TRIGGER applies to the table on which a trigger is defined.
DROP granted for the specified GLOP set to the specified user or database.
This privilege is not granted automatically when a user or database is created.
This privilege is automatically granted to the creator and owner of the GLOP set.
DROP PROFILE and DROP ROLE can only be granted to a user or role. They cannot be granted on an object.
Privilege applies to all tables in the specified database.
Privilege applies to all user-defined functions or macros in the specified database.
For the grantee to use the privilege on a user-defined function or macro, the immediate owner of the macro or UDF must have appropriate privileges on the objects referenced by the macro or UDF.
DROP PROFILE and DROP ROLE can only be granted to a user or role. They cannot be granted on an object.
Privilege applies to the named data table or journal table only.
Privilege applies to the specified macro if the keywords FUNCTION, SPECIFIC
FUNCTION, or PROCEDURE are not specified.
For the grantee to use the privilege on a user-defined function or macro, the immediate owner of the macro must have appropriate privileges on the objects referenced by the macro.
Privilege applies to the specified user-defined functions or stored procedures if the keywords FUNCTION, SPECIFIC
FUNCTION, or PROCEDURE are specified.
Privilege applies to all user-defined functions or stored procedures in the specified space.
For the grantee to use the privilege on a procedure, the immediate owner of the stored procedure must have the appropriate privileges on the objects referenced by the stored procedure.
Not applicable.
Privilege applies to the specified user-defined functions or stored procedures.
For the grantee to use the privilege on a procedure, the immediate owner of the stored procedure must have the appropriate privileges on the objects referenced by the stored procedure.
Privilege applies on a table or hash or join index.
INDEX also grants the privilege to collect statistics on an eligible database object.
SQL Data Control Language 61
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
PROFILE
ROLE
Privilege
REFERENCES
REPLCONTROL
SHOW
STATISTICS
UDTMETHOD
Object (Database, User, Role, PUBLIC)
CREATE PROFILE, DROP PROFILE, CREATE
ROLE, and DROP ROLE can only be granted to users and roles. They cannot be granted on an object.
Not applicable.
Privilege is a total system privilege and is not granted to or revoked from specific tables or databases.
REPLCONTROL can only be granted to a user.
User DBC can grant REPLCONTROL to any other user WITH GRANT OPTION.
Not applicable.
Privilege applies on a table, hash or join index, or database.
Privilege does not allow the grantee the ability to perform any operations on the granted database object other than to make a
HELP or SHOW request against it.
Not applicable.
Can only be granted on the SYSUDTLIB database.
Privilege applies to all UDTs, UDMs, and UDFs contained within the SYSUDTLIB database.
Effectively grants UDTUSAGE on all UDTs contained within SYSUDTLIB as well as
UDTTYPE on the SYSUDTLIB database.
Privilege applies to the specified UDT object.
•
Grants ability to access a UDT column in a table or view.
•
Grants CREATE TYPE, ALTER TYPE, and
DROP TYPE including method signatures.
•
Grants CREATE ORDERING and DROP
ORDERING.
•
Grants CREATE CAST and DROP CAST.
•
Grants CREATE TRANSFORM and DROP
TRANSFORM.
•
Grants CREATE TABLE for UDT columns.
•
Grants ability to reference any UDT in a UDF or stored procedure.
•
Grants ability to execute all methods.
•
Grants CREATE METHOD, ALTER
METHOD, and REPLACE METHOD.
Table, View, Function, GLOP, Method, UDT,
Procedure, or Macro
CREATE PROFILE, DROP PROFILE,
CREATE ROLE, and DROP ROLE can only be granted to users and roles. They cannot be granted on an object.
Privilege applies on a table or column of the table.
Grants same privilege to collect statistics as
DROP TABLE or INDEX.
Privilege applies on a table, hash or join index, or database.
Not applicable.
62 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Privilege
UDTTYPE
UDTUSAGE
Object (Database, User, Role, PUBLIC)
Can only be granted on the SYSUDTLIB database.
Privilege applies to all UDTs, UDMs, and UDFs contained within the SYSUDTLIB database.
Effectively grants UDTUSAGE on all UDTs contained within the SYSUDTLIB database.
Privilege applies to the specified UDT object.
•
Grants ability to access a UDT column in a table or view.
•
Grants CREATE TYPE and ALTER TYPE only if no method signatures are specified.
•
Grants DROP TYPE.
•
Grants CREATE ORDERING and DROP
ORDERING.
•
Grants CREATE CAST and DROP CAST.
•
Grants CREATE TRANSFORM and DROP
TRANSFORM
•
Grants CREATE TABLE for UDT columns.
•
Grants ability to reference any UDT in a UDF or stored procedure.
•
Grants ability to execute all methods.
Can be granted on the following:
•
SYSUDTLIB database.
•
TYPE.
Privilege applies to all UDTs, UDMs, and UDFs contained within the SYSUDTLIB database.
Table, View, Function, GLOP, Method, UDT,
Procedure, or Macro
Not applicable.
Privilege applies to the specified UDT object.
•
Grants ability to access a UDT column in a table or view.
•
Grants ability to execute all methods associated wholly with the specified UDT, but no others.
Granting Privileges on Global Temporary and Volatile Tables
GRANT always applies to the base global temporary table and never to a materialized instance. Just as with permanent tables, a user must have the appropriate privileges before submitting a GRANT request.
Because Teradata Database does not check privileges for volatile tables, you cannot GRANT privileges to them.
SQL Data Control Language 63
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Verifying Privileges on Views, Macros, and Stored Procedures
WHEN this statement is submitted … The system verifies that the creator has these privileges …
CREATE MACRO any needed to perform the SQL statements in the macro body.
CREATE PROCEDURE (SQL
Form)
•
CREATE PROCEDURE
(External Form)
•
ALTER PROCEDURE (External
Form)
CREATE PROCEDURE … SQL
SECURITY OWNER (both forms) any needed to perform the SQL statements in the stored procedure body.
CREATE EXTERNAL PROCEDURE and any needed to access the specified tables, columns, and views using any of the valid API function calls.
CREATE VIEW
CREATE OWNER PROCEDURE and either of the following:
•
For the SQL form, any needed on the underlying tables, columns, and views to perform the SQL statements in the stored procedure body.
•
For the external form, any needed on the underlying tables, columns, and views using any of the valid API function calls.
SELECT on the underlying base tables and views.
Teradata Database also verifies that the appropriate privileges exist on the target objects for any user who attempts to access a view, or perform a macro or stored procedure. This ensures that a change to a target object does not cause a violation of privileges when the view, macro, or stored procedure referencing that object is invoked.
REPLCONTROL Privilege
The REPLCONTROL privilege controls two separate functions:
•
The ability to define and manage replication groups. See the following for more information:
•
“CREATE REPLICATION GROUP’ in SQL Data Definition Language
•
“CREATE REPLICATION RULESET” in SQL Data Definition Language
•
“SET SESSION OVERRIDE REPLICATION” in SQL Data Definition Language
•
“HELP REPLICATION GROUP” in SQL Data Definition Language
•
The ability to perform SQL DML updates
2
to replication group member tables while they are in a state that would otherwise not permit updates to be made.
Be exceedingly careful when granting the REPLCONTROL privilege to a user because of the high risk to enterprise security involved. REPLCONTROL applies to all objects in the system, and a user who has been granted this privilege could create a replication group consisting of any tables defined in the system.
2. The term update here applies to any of the operations performed by the following SQL DML statements:
DELETE, INSERT, MERGE, and UPDATE.
64 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
CTCONTROL Privilege
CTCONTROL authorizes a user to grant or revoke the CONNECT THROUGH privilege using the GRANT CONNECT or REVOKE CONNECT statements. You can only grant
CTCONTROL to specific users.
The following rules apply to granting the CTCONTROL privilege:
•
The user specified by user_name must be an existing user of the system. Note that
user_name cannot specify a role. If you attempt to grant CTCONTROL to a role, the request aborts and returns a message to the user.
•
User DBC can grant the CTCONTROL privilege to any other user WITH GRANT
OPTION.
•
To submit a GRANT request for the CTCONTROL privilege to a user, you must either be user DBC or a user who has previously been granted the CTCONTROL privilege WITH
GRANT OPTION.
WITH GRANT OPTION permits the grantee to grant the privilege to other users.
SHOW Privilege
The SHOW privilege enables you to have access to database object definitions and create text without having access to the data contained by the objects on which the privilege is granted.
For example, SHOW permits a user to execute HELP and SHOW requests against an object while at the same time not being able to SELECT from it. Any SQL statement that requires any privilege (such as the HELP and SHOW statements) to be executed can be granted the SHOW privilege.
SHOW is an explicit privilege. Teradata Database does not grant the creator of an object this privilege automatically on the created user, database, or database object; SHOW must be granted explicitly. You must have the SHOW privilege WITH GRANT OPTION to be able to grant this privilege explicitly to other users and databases.
User DBC automatically has the SHOW privilege and can grant it on dictionary tables to other users and databases.
Granting Privileges on Queue Tables
GRANT both the SELECT and DELETE privileges on the queue table to the user, database, role, or PUBLIC from which a user performs consume mode SELECT statements.
GLOP Privileges
Teradata Database does not grant any of the GLOP privileges automatically when a database or user is created. All GLOP privileges must be explicited granted, even when the privileges have been granted by a user who possesses the WITH GRANT OPTION privilege.
SQL Data Control Language 65
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
There are three GLOP privileges:
•
CREATE GLOP enables the user to whom it is granted to perform the CREATE GLOP SET statement to create a new GLOP set.
•
DROP GLOP enables the user to whom it is granted to perform the DROP GLOP SET statement to drop an existing GLOP set. DROP GLOP is granted automatically to the creater and owner of a GLOP set.
•
GLOP MEMBER enables an external routine to access a GLOP set that is not contained within its containing user or database. Specifically, GLOP MEMBER enables the GLOP set clause referenced in the function, method, or procedure definition to use the GLOP set specified in the MEMBER OF GLOP SET clause.
You can also specify the keyword GLOP by itself to signify both the CREATE GLOP and DROP
GLOP privileges (see
“Privilege Abbreviations” on page 53 ).
Granting Privileges on Stored Procedures
The following table describes the privileges of different types of users or grantors with respect to stored procedures-specific privileges:
This privilege...
ALTER PROCEDURE
CREATE PROCEDURE
ALTER EXTERNAL
PROCEDURE
DROP PROCEDURE
Is granted to...
By...
user DBC implicitly.
user DBC. other users, roles, databases, or
PUBLIC explicitly.
•
user DBC.
•
an owner of the user or database where the owner has this privilege WITH GRANT
OPTION on itself.
•
a database or user having this privilege
WITH GRANT OPTION on the database or user for which the privilege is being granted.
user DBC implicitly.
user DBC. other users explicitly.
•
user DBC.
•
a database or user having this privilege
WITH GRANT OPTION on itself.
all users, roles, databases, or
PUBLIC explicitly.
default.
66 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
This privilege...
EXECUTE
PROCEDURE or
EXEC PROCEDURE
Is granted to...
By...
user DBC implicitly.
user DBC.
the creator of a stored procedure automatically.
other users, roles, databases, and
PUBLIC explicitly.
the creator.
Except for user DBC, owners do not implicitly have this privilege.
If the immediate owner of the procedure is different from its creator, the owner does not receive this privilege automatically.
•
user DBC.
•
an owner of the user or database where the owner has this privilege WITH GRANT
OPTION on itself.
•
a database or user having this privilege
WITH GRANT OPTION on the database or user for which the privilege is being granted.
External stored procedures (see “CREATE PROCEDURE (External Form)/REPLACE
PROCEDURE (External Form)” in SQL Data Definition Language for a description of external stored procedures) also require the ALTER EXTERNAL PROCEDURE and CREATE
EXTERNAL PROCEDURE (see
“CREATE EXTERNAL PROCEDURE Privilege” on page 68 )
privileges. You need the ALTER EXTERNAL PROCEDURE privilege to be able to perform the
ALTER PROCEDURE (External Form) statement (see “ALTER PROCEDURE (External
Form)” in SQL Data Definition Language).
The ALTER PROCEDURE (External Form) statement provides the ability to recompile existing external stored procedures. The intent of the ALTER EXTERNAL PROCEDURE privilege is to give DBAs the ability to change the execution mode or to recompile an existing external stored procedure in situations where the current library is corrupt or the system has been reloaded. Do not grant this privilege to any user other than a DBA.
This privilege permits DBAs to use ALTER PROCEDURE (External Form) requests to change the execution mode for a particular external stored procedure to execute either directly in unprotected mode (EXECUTE NOT PROTECTED) or as a separate process in protected mode (EXECUTE PROTECTED).
ALTER EXTERNAL PROCEDURE is not an automatic privilege for a user when you create a database or user. Instead, the DBA retains the privilege (initially, only user DBC holds the privilege implicitly) and assigns it judiciously only for external stored procedures that are completely debugged and production-certified, so can have their execution mode changed from EXECUTE PROTECTED to EXECUTE NOT PROTECTED (see “ALTER PROCEDURE
(External Form)” in SQL Data Definition Language).
Do not grant users the ability to perform the ALTER PROCEDURE (External Form) statement without carefully weighing the pros and cons, because doing so could easily compromise the integrity of the system if the privilege is misused (also see
PROCEDURE Privilege” on page 68 ).
SQL Data Control Language 67
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
You can grant the ALTER EXTERNAL PROCEDURE privilege on either a specific external stored procedure or to an entire database or user.
Stored Procedure-SpecificPrivileges
The following rules apply to privileges specific to stored procedures:
•
CREATE PROCEDURE and CREATE EXTERNAL PROCEDURE are database- or user-level privilege only.
•
ALTER PROCEDURE, ALTER EXTERNAL PROCEDURE, DROP PROCEDURE, and
EXECUTE PROCEDURE are allowed on databases, users, or specified stored procedures.
•
DROP and EXECUTE can be used as abbreviations for DROP PROCEDURE and
EXECUTE PROCEDURE while granting privileges, if you specify the object type
PROCEDURE as a qualifier for the stored procedure name.
The following happens if PROCEDURE is not specified before the object name:
IF the request is...
GRANT EXECUTE
THEN...
the object is assumed to be a macro.
If no macro of that name exists, an error or failure is returned.
an error or failure is returned.
GRANT DROP
CREATE EXTERNAL PROCEDURE Privilege
Do not grant the CREATE EXTERNAL PROCEDURE privilege to any user unless they are explicitly assigned to code an external procedure for your site. Even then, you should restrict this privilege to only your most trusted programmers. You must also ensure that the external procedure, once written, is thoroughly tested to verify that it does not compromise the system in any way.
The system does not grant the CREATE EXTERNAL PROCEDURE privilege automatically when you create a user or database. Nor is CREATE EXTERNAL PROCEDURE granted on a database unless an owner explicitly has this privilege on itself WITH GRANT OPTION.
Note: This functionality is different from the CREATE MACRO privilege, where the system grants CREATE MACRO automatically when you create a database or user, as well as the privilege held implicitly by an owner.
External stored procedures execute as part of the system when running in unprotected mode
(see “CREATE PROCEDURE (External Form)/REPLACE PROCEDURE (External Form)” in
SQL Data Definition Language), while protected mode external stored procedures run in a separate process as an ordinary user named tdatuser.
Teradata Database is configured as a trusted user or system user. This means that on a
UNIX-based system, for example, it has all of the privileges of the root user. For
Windows-based systems, Teradata Database runs in system mode. This means it can access and modify any file on the local set of disks even if the file is protected or read only. There is no way to protect the system from a malicious user who has been granted these privileges.
68 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Granting Privileges on User-Defined Functions
The rules for granting privileges on user-defined functions are identical to those for macros except for the CREATE FUNCTION and EXECUTE FUNCTION privileges, as documented in the following table, which explains which user-defined function-related privileges are granted explicitly or not:
Privilege
ALTER FUNCTION
Usage Notes
•
Not granted automatically to the creator when it creates a database or user.
•
Not granted automatically to a database or user when it creates a database or user.
•
Held implicitly only by user DBC.
CREATE FUNCTION
DROP FUNCTION
•
Not granted automatically to the creator when it creates a database or user.
•
Held implicitly only by user DBC.
•
Granted automatically WITH GRANT OPTION to the creator of a user, database, or function.
•
Granted automatically without grant option to a created database or user on itself.
•
Held implicitly on a database or user for an owner of that database or user.
EXECUTE FUNCTION
•
Granted automatically WITH GRANT OPTION to the creator of a function.
•
Not granted automatically to the creator to the creator when it creates database or user.
•
Held implicitly only by user DBC.
Furthermore, all newly created user-defined functions are performed in protected mode by default (see “ALTER FUNCTION” in SQL Data Definition Language).
3
The ALTER FUNCTION privilege should be restricted to DBAs exclusively. Its intent is to permit a user to perform the ALTER FUNCTION statement, which can be used to change the execution mode of a UDF. Changing the execution mode for a user-defined function from
PROTECTED to NOT PROTECTED, for example, is not an act that should be performed without exercising extreme caution.
3. This is also true for all newly created methods and external stored procedures. See “ALTER METHOD” in SQL Data Definition Language and “ALTER PROCEDURE” in SQL Data Definition Language, respectively.
SQL Data Control Language 69
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
CREATE FUNCTION Privilege
Caution:
UDFs execute as part of the database software, which is defined as a trusted user or system user. For example, on UNIX-based systems, the database has all the privileges of the root user, while on Windows-based systems, it runs in system mode, which means it can access and modify any file on the local disks even if they are protected or read-only. As a result, improperly debugged or maliciously written user-defined functions can wreak havoc on your databases. Because of this, you should grant the CREATE FUNCTION privilege with particular care, providing it only to trusted users who are coding UDFs.
If you are granted the CREATE FUNCTION privilege on a database or user, then any function you create in that database or user has the following privileges WITH GRANT OPTION on that function by default:
•
DROP FUNCTION
•
EXECUTE FUNCTION
DROP FUNCTION Privilege
You must specify DROP FUNCTION to grant that privilege on a database object. If you are granting the privilege on a particular UDF only, then you can specify DROP without also specifying the FUNCTION keyword.
When creators have WITH GRANT OPTION on a function, they can grant the following privileges to another user on that function:
•
DROP FUNCTION
•
EXECUTE FUNCTION
Notice that by holding the DROP FUNCTION privilege on a function, a user can also replace that function. If that user drops the function, however, they cannot replace it at a later time without also being granted the CREATE FUNCTION privilege.
EXECUTE FUNCTION Privilege
You must specify EXECUTE FUNCTION to grant that privilege on all functions in a database.
For example, the following GRANT statement grants the EXECUTE privilege on all functions in SYSLIB:
GRANT EXECUTE FUNCTION ON SYSLIB TO user_xyz;
You need only specify EXECUTE to grant the EXECUTE FUNCTION privilege on an individual UDF. For example, the following GRANT statement grants the EXECUTE privilege only on the function with the specific function name sales to user_xyz:
GRANT EXECUTE ON SPECIFIC FUNCTION SYSLIB.sales TO user_xyz;
UDT-Related Privileges
Initially, only user DBC has UDT privileges on SYSUDTLIB, which DBC holds implicitly. Any other user or role must be explicitly granted UDT privileges on SYSUDTLIB in order to execute SQL statements that involve UDTs.
70 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
There are three UDT-related privileges:
•
UDTMETHOD (see “UDTMETHOD Privilege” on page 73 ).
UDTMETHOD allows a user to use, create, drop, or modify any UDT and its methods without restriction.
You can only grant this privilege at the database level, specifically on the SYSUDTLIB database: there are no UDT object-level privileges for UDTMETHOD.
•
UDTTYPE (see
“UDTTYPE Privilege” on page 73 ).
UDTTYPE allows a user to create, alter and drop UDTs in addition to the privileges
UDTUSAGE permits.
You can only grant this privilege at the database level: there are no UDT object-level privileges for UDTTYPE.
•
UDTUSAGE (see “UDTUSAGE Privilege” on page 72 ).
UDTUSAGE allows a user to execute all SQL statements that reference existing UDTs and their existing methods. This means that a user with the UDTUSAGE privilege on a particular UDT can perform the following operations:
•
Create a new table that is defined with a column having that UDT type.
•
Alter an existing table that is defined with a column having that UDT type.
•
Reference that UDT in a query, UDF, or stored procedure.
•
Execute all methods that are associated wholly with the UDT type.
Methods that involve additional UDTs require you to have the UDTUSAGE privilege on any such UDTs as well.
UDTUSAGE does not permit a user to perform any of the following operations:
•
Create new UDTs.
•
Drop existing UDTs.
•
Alter the ordering, casting, or transform behavior of existing UDTs.
•
Create new methods.
•
Drop or replace existing methods.
Unlike UDTMETHOD and UDTTYPE, you can grant UDTUSAGE on either a specific UDT
(as
TYPE UDT_name
) or on the entire SYSUDTLIB database.
ALL PRIVILEGES and UDTs
When you specify ALL PRIVILEGES on the SYSUDTLIB database, the system grants the
UDTMETHOD privilege along with the other privileges ALL PRIVILEGES provides, assuming the creator has the privilege WITH GRANT OPTION.
A user who is granted UDTMETHOD via the ALL PRIVILEGES path WITH GRANT
OPTION can then grant others the UDTUSAGE, UDTTYPE, or UDTMETHOD privileges, optionally also with the WITH GRANT option.
SQL Data Control Language 71
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
UDTUSAGE Privilege
The UDTUSAGE privilege allows a user to use a UDT in a table or view and to execute all methods associated wholly with that UDT. They cannot create or delete UDTs, create, alter, or delete methods, or alter the behavior of a UDT with respect to ordering, casting, or transform functionality.
You can grant UDTUSAGE at either the database or UDT object level.
IF granted at this level …
database
UDT object
UDTUSAGE must be granted on the …
SYSUDTLIB database only.
name of the UDT.
A user with the UDTUSAGE privilege on a specific UDT can perform the following statements and operations:
•
CREATE TABLE or ALTER TABLE for tables that contain columns that use that UDT.
•
Reference that UDT in queries, UDFs, and stored procedure that reference the UDT.
•
Execute all methods associated wholly with the UDT.
Methods that involve other UDTs also require the UDTUSAGE privilege on those UDTs.
With regard to nested structured UDTs, be aware that privileges are not automatically inherited from their parents. For example, if you have been granted UDTUSAGE on a top-level structured UDT attribute, you can then specify a column with that type in a create table operation. However, that privilege does not grant you the ability to use observer or mutator methods on any of the structured attributes in the lower layers of that UDT, nor can you invoke any of the methods defined for those lower layered attributes.
To enable that sort of access, you must grant UDTUSAGE explicitly on each individual UDT component of the nested UDT type or grant UDTUSAGE explicitly on the SYSUDTLIB database.
UDTUSAGE is not an automatically granted privilege. A user must either be granted this privilege explicitly or acquire it through a role. Users who are granted UDTUSAGE WITH
GRANT option can then grant others the UDTUSAGE privilege, optionally with the WITH
GRANT option privilege.
UDTUSAGE is represented by the code UU in the AccessRight column of the DBC.AccessRights table.
User DBC has implicit UDT privileges on the SYSUDTLIB database.
Any other user or role that needs to access the UDT-related objects in SYSUDTLIB must first be granted the appropriate UDT privileges on SYSUDTLIB or a specific UDT in the
SYSUDTLIB database explicitly.
72 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
UDTTYPE Privilege
The UDTTYPE privilege gives a user all the privileges associated with UDTUSAGE as well as permitting that user to execute all SQL statements that reference UDTs without creating new methods or dropping or replacing existing methods.
A user with the UDTTYPE privilege can perform the following statements and operations:
•
CREATE TYPE without specifying method signatures.
•
DROP TYPE.
•
ALTER TYPE without adding or dropping method signatures.
•
CREATE ORDERING and DROP ORDERING.
•
CREATE CAST and DROP CAST.
•
CREATE TRANSFORM and DROP TRANSFORM.
•
CREATE TABLE with UDT columns.
•
Reference any UDT in an SQL statement, UDF, or stored procedure.
•
Perform all methods.
The specified database_name in the ON clause must be SYSUDTLIB.
UDTTYPE is not an automatically granted privilege. A user must either be granted this privilege or acquire it through a role. Users who are granted UDTTYPE WITH GRANT
OPTION can then grant others either the UDTUSAGE or UDTTYPE privilege, optionally with the WITH GRANT option privilege.
UDTTYPE is represented by the code UT in the AccessRight column of the DBC.AccessRights table.
UDTMETHOD Privilege
The UDTMETHOD privilege allows a user to use any UDT and its methods without any restrictions. Its functionally includes both of the following privileges:
•
UDTUSAGE on all UDTs in the SYSUDTLIB database.
•
UDTTYPE on the SYSUDTLIB database.
A user with the UDTMETHOD privilege can perform the following statements and operations:
•
CREATE TYPE with or without specifying method signatures.
•
DROP TYPE.
•
ALTER TYPE with or without adding or dropping method signatures.
•
CREATE ORDERING and DROP ORDERING.
•
CREATE CAST and DROP CAST.
•
CREATE TRANSFORM and DROP TRANSFORM.
•
CREATE TABLE with UDT columns.
SQL Data Control Language 73
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
•
Reference any UDT in an SQL statement, UDF, or stored procedure.
•
Execute all methods.
•
CREATE METHOD and ALTER METHOD and REPLACE METHOD.
The specified database_name in the ON clause must be SYSUDTLIB.
UDTMETHOD is not an automatically granted privilege. A user must either be granted this privilege explicitly, acquire it through ALL PRIVILEGES, or acquire it through a role. Users who are granted UDTMETHOD WITH GRANT OPTION can then grant others the
UDTUSAGE, UDTTYPE, or UDTMETHOD privilege, optionally with the WITH GRANT option.
UDTMETHOD is represented by the code UM in the AccessRight column of the
DBC.AccessRights table.
Caution:
UDMs execute as part of the database software, which is defined as a trusted user or system user. For example, on UNIX-based systems, the database has all the privileges of the root user, while on Windows-based systems, it runs in system mode, which means it can access and modify any file on the local disks even if they are protected or read-only. As a result, improperly debugged or maliciously written user-defined methods can wreak havoc on your databases. Because of this, you should grant the UDTMETHOD privilege with particular care, providing it only to trusted users who are coding UDT-related database objects.
Granting Privileges to Roles
Roles define privileges on database objects. A database administrator can create different roles for different job functions and responsibilities, grant specific privileges on database objects to the roles, and then grant membership to the roles to users. Users who are members of a role can access all the objects for which the role has privileges. A role that has roles granted to it cannot be granted to a role.
Roles cannot be granted the CREATE DATABASE, CREATE ROLE, CREATE PROFILE,
CREATE USER, DROP DATABASE, DROP ROLE, DROP PROFILE, or DROP USER privileges.
Roles cannot be granted on a database or PUBLIC.
To grant role membership to users or other roles, use the GRANT (Role Form) statement. For more information, see
“GRANT (Role Form)” on page 38
.
Case Study: Granting SELECT on a View
Assume Allen creates two objects: a table named Allen.BaseTable, and a view on that table named Allen.ViewA. The system verifies that Allen has SELECT privilege on Allen.BaseTable when ViewA is created.
Also assume Allen grants the SELECT privilege on ViewA to Bobby. Bobby then creates
Bobby.ViewB, which references Allen.ViewA. The Parser verifies that Bobby has SELECT privilege on Allen.ViewA when Bobby.ViewB is created.
74 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
3
4
The following stages summarize this process:
1
2
Allen creates the base table Allen.BaseTable.
Allen creates the view Allen.ViewA that references Allen.BaseTable.
5
He has the SELECT privilege on Allen.BaseTable.
Allen grants the SELECT privilege on Allen.ViewA to Bobby.
Bobby creates Bobby.ViewB that references Allen.ViewA.
Bobby has the SELECT privilege on Allen.ViewA.
End of process.
Bobby now wants to grant the SELECT privilege on Bobby.ViewB to Chuck. Bobby can grant the privilege to Chuck, but Chuck cannot use the views in a query unless Allen grants Bobby the SELECT privilege on Allen.ViewA WITH GRANT OPTION.
The same privilege is required when a macro references an object owned by a user other than its creator. For example, assume that the macro Bobby.MacroB deletes rows from Allen.ViewA.
Other users cannot execute Bobby.MacroB unless Bobby has the EXECUTE privilege WITH
GRANT OPTION on Bobby.MacroB.
Case Study: More on Views
1
2
3
Assume that the view Bobby.ViewB references the view Allen.ViewA, which in turn references
Allen.BaseTable. When Bobby enters the following statement, the system checks that the privileges in the table following the statement exist.
GRANT INSERT, DELETE
ON Bobby.ViewB TO Chuck;
The following stages explain this process:
Bobby has INSERT WITH GRANT OPTION on Bobby.ViewB or on himself.
Bobby has DELETE WITH GRANT OPTION on Bobby.ViewB or on himself.
End of process.
Unless revoked, Bobby has these privileges on Bobby.ViewB explicitly because they were granted to him automatically when he created the view.
Bobby also had these privileges on himself because they were granted explicitly when user
Bobby was created.
Because Bobby owns Bobby.ViewB, he also has these privileges implicitly.
Implicit privileges cannot be revoked. For any other type of privilege, however, the system might not find one or more of the necessary privileges. In this case, the system returns an error message to the user submitting the GRANT statement and the statement is not performed.
SQL Data Control Language 75
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
The breakdown of privilege types for this example is as follows:
FOR this category of privilege …
Automatic
Explicit
THIS individual … HAS this privilege …
Bobby INSERT WITH GRANT OPTION
Allen
DELETE WITH GRANT OPTION
INSERT WITH GRANT OPTION
Bobby
DELETE WITH GRANT OPTION
INSERT WITH GRANT OPTION
DELETE WITH GRANT OPTION
ON this object …
Bobby.ViewB
Allen.BaseTable
Allen.ViewA
Case Study: Stored Procedures
Assume that user_1 is to be granted CREATE PROCEDURE privilege on the accounting database. Assume that the grantor is an owner of the database and that she has the explicit
CREATE PROCEDURE and EXECUTE PROCEDURE privileges WITH GRANT OPTION on herself.
4
The following GRANT request must be submitted so that user_1 can create procedures in the accounting database:
GRANT CREATE PROCEDURE
ON accounting
TO user_1;
To grant CREATE PROCEDURE, DROP PROCEDURE, and EXECUTE PROCEDURE privileges to user_1 on all stored procedures in the accounting database, submit the following
GRANT request:
GRANT CREATE PROCEDURE, EXECUTE PROCEDURE, DROP PROCEDURE
ON accounting
TO user_1;
If the keyword PROCEDURE is specified without CREATE or DROP in a GRANT request, it confers both CREATE PROCEDURE and DROP PROCEDURE privileges (at the user or database level).
The following example assumes that the grantor has the privileges required to grant CREATE
PROCEDURE and DROP PROCEDURE privileges to user_1 on the accounting database:
GRANT PROCEDURE
ON accounting
TO user_1;
76
4. This grant cannot be made unless one of the following is true:
• The grantor has both the CREATE PROCEDURE and EXECUTE PROCEDURE privileges
WITH GRANT OPTION on itself and on the user or database WITH GRANT OPTION.
• The grantor is user DBC.
SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Assume that user_1 needs to be granted EXECUTE PROCEDURE privilege WITH GRANT
OPTION on the stored procedure daily_updates in the database accounting. Assume that the grantor has the EXECUTE PROCEDURE WITH GRANT OPTION privilege on the stored procedure or its containing database. The following GRANT request needs to be submitted:
GRANT EXECUTE ON PROCEDURE accounting.daily_updates
TO user_1
WITH GRANT OPTION;
This request can also be specified using the following syntax:
GRANT EXECUTE PROCEDURE ON accounting.daily_updates
TO user_1
WITH GRANT OPTION;
Note that the following GRANT request returns an error because the syntax is valid only for macros, and daily_update is not a macro:
GRANT EXECUTE ON accounting.daily_update
TO user_1
WITH GRANT OPTION;
To grant ALTER PROCEDURE, EXECUTE PROCEDURE, and DROP PROCEDURE privileges to user_1 on the stored procedure weekly_update, the necessary GRANT request looks like either of these requests, assuming the grantor has the privileges to perform the grant:
GRANT ALTER PROCEDURE, EXECUTE, DROP PROCEDURE
ON PROCEDURE weekly_update
TO user_1;
GRANT ALL ON PROCEDURE accounting.weekly_update
TO user_1;.
Example 1: Granting Privileges to a Group of Users
The following request grants privileges to a group of users. In this example, all users created under the finance database are granted the privilege to SELECT data from the department table, which is in the personnel database:
GRANT SELECT
ON personnel.department
TO ALL finance;
Example 2: Granting Privileges to PUBLIC
The PUBLIC keyword (see “PUBLIC Privileges” on page 27
) grants privileges to all existing and future Teradata Database users:
GRANT SELECT
ON personnel.department
TO PUBLIC;
SQL Data Control Language 77
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Example 3: Granting SELECT on Any Object
The following statement allows Moffit to retrieve information from any object in the personnel database:
GRANT SELECT
ON personnel
TO moffit;
Example 4: Granting SELECT, INSERT, UPDATE, and DELETE on Any Object
The following statement allows Peterson to perform selects, inserts, updates, and deletes on any object in the personnel database:
GRANT SELECT, INSERT, UPDATE, DELETE
ON personnel
TO peterson;
Example 5: Granting CREATE and DROP On Users in a Database
The following statement allows Phan to create and drop users in the personnel database:
GRANT USER
ON personnel
TO phan;
Example 6: Using GRANT SELECT TO ALL
The following statement allows all current and future users created under the personnel database to select data from the department table:
GRANT SELECT
ON personnel.department
TO ALL personnel;
Example 7: Using WITH GRANT OPTION
WITH GRANT OPTION applies to the indicated privileges only.
In this example, user George grants all privileges that he has on his own user space to user
Marston with the following restrictions:
•
George can grant only those privileges for which he has WITH GRANT OPTION at the user level.
•
George must have the WITH GRANT OPTION privilege on the privileges he grants to
Marston.
GRANT ALL
ON marston
TO marston
WITH GRANT OPTION;
78 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Example 8: Using CREATE ROLE and DROP ROLE
The following request allows user Franklin to create and drop roles:
GRANT ROLE
TO Franklin;
Notice that this form does not have an ON clause. If you specify an ON clause for the role privilege, the system returns an error.
Example 9: Granting Privileges to a Role
The following request grants privileges to a role. In this example, the finance role is granted the privilege to SELECT data from the department table, which is in the personnel database:
GRANT SELECT
ON personnel.department
TO Finance;
All users who are granted membership to the finance role also inherit the privilege to SELECT data from the department table in the personnel database when the role is activated for the user.
Example 10: Granting Privileges Related to Triggers
The following request grants CREATE TRIGGER and DROP TRIGGER privileges to user
TrigUser for any table in database TrigDB:
GRANT CREATE TRIGGER, DROP TRIGGER
ON TrigDB
TO TrigUser;
The following request grants CREATE TRIGGER and DROP TRIGGER privileges to user
TrigUser for TrigTable as the subject table.
GRANT CREATE TRIGGER, DROP TRIGGER
ON TrigTable
TO TrigUser;
You can also grant the same privileges as in the previous requests using the short form
TRIGGER to mean both CREATE TRIGGER and DROP TRIGGER.
For example:
GRANT TRIGGER
ON TrigDB TO TrigUser;
GRANT TRIGGER
ON TrigTable
TO TrigUser;
SQL Data Control Language 79
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Example 11: Granting Privileges on a Function
The following GRANT requests grant the following respective privileges:
•
ALTER FUNCTION on the specific function find_text to users named user_dba and
user_in_house.
•
ALTER FUNCTION on all UDFs in the SYSLIB database to user_dba.
•
CREATE FUNCTION on the database document_db to user_dba.
•
EXECUTE FUNCTION on the overloaded function text_process to user sammy.
GRANT ALTER FUNCTION
ON SPECIFIC FUNCTION find_text
TO user_dba, user_in_house;
GRANT ALTER FUNCTION
ON syslib
TO user_dba;
GRANT CREATE FUNCTION
ON document_db
TO user_dba, user_in_house;
GRANT EXECUTE
ON FUNCTION text_process(CHAR,CHAR,INTEGER)
TO sammy;
Example 12: Granting the CREATE EXTERNAL PROCEDURE Privilege
The following example grants user asst_dba the privilege to create an external stored procedure:
GRANT CREATE EXTERNAL PROCEDURE
ON PROCEDURE classify
TO asst_dba;
Example 13: Granting the UDTUSAGE Privilege
The following GRANT request grants the following respective privileges:
•
UDTUSAGE on the SYSUDTLIB database to the user named tester1.
•
UDTUSAGE on the UDT named circle to the user named tester3.
•
UDTUSAGE on the UDT named square in database SYSUDTLIB to the user named
tester4.
GRANT UDTUSAGE
ON SYSUDTLIB
TO tester1;
GRANT UDTUSAGE
ON TYPE circle
TO tester3;
GRANT UDTUSAGE
ON TYPE SYSUDTLIB.square
TO tester4;
80 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
Example 14: Granting the UDTTYPE Privilege
The following GRANT request grants the UDTTYPE privilege on database SYSUDTLIB to the user named tester2:
GRANT UDTTYPE
ON SYSUDTLIB
TO tester2;
Example 15: Granting the UDTMETHOD Privilege
The following GRANT requests grant the following respective privileges:
•
UDTMETHOD on SYSUDTLIB to the user named user_DBA with grant option.
•
UDTMETHOD on SYSUDTLIB to the role named developer_role.
GRANT UDTMETHOD
ON SYSUDTLIB
TO user_DBA WITH GRANT OPTION;
GRANT UDTMETHOD
ON SYSUDTLIB
TO developer_role;
Example 16: Granting the REPLCONTROL Privilege
The following example grants user s_barroso the privilege to create, alter, and drop replication groups.
GRANT REPLCONTROL
TO s_barroso;
Example 17: Granting the CTCONTROL Privilege
The following example grants user kate the privilege to grant the CONNECT THROUGH privilege to user trusteduser2:
GRANT CTCONTROL
ON trusteduser2
TO kate;
To then execute a GRANT CONNECT THROUGH request (see “GRANT CONNECT
), trusteduser2 requires the following privileges:
•
CTCONTROL on herself.
•
GRANT … WITH ADMIN OPTION on any role specified (see “GRANT (Role Form)” on page 38
.
•
DROP USER on any PERMANENT users specified as proxy users.
Example 18: Granting GLOP Privileges
The enterprise wants the sales_bonus UDF to access the special sales GLOP. User Joe creates both the UDF and the GLOP in SYSLIB. The following requests must be executed to make this happen:
SQL Data Control Language 81
Chapter 2: SQL Data Control Language Statement Syntax
GRANT (SQL Form)
A user WITH GRANT OPTION must execute the following GRANT request:
GRANT GLOP ON syslib TO Joe;
Assuming that Joe already has privileges to create a function in SYSLIB, Joe then executes the following requests:
Joe creates the GLOP set object first to enable a GLOP to be added.
CREATE GLOP SET syslib.sales;
Joe then calls the procedure GLOP_Add to add the sales GLOP and associates it with SYSLIB.
CALL DBCExtension.GLOP_Add('syslib.sales',...);
Finally, Joe creates the function sales_bonus in SYSLIB.
CREATE FUNCTION syslib.sales_bonus( … )
RETURNS DECIMAL(6,2)
LANGUAGE C
MEMBER OF GLOP SET syslib.sales
PARAMETER STYLE SQL
EXTERNAL;
SYSLIB is a public database. For this reason, the Security Administrator instead decides to place the sales GLOP in the finance database, and to make the Finance department responsible for creating the GLOP data. She also wants the UDF to be contained within the finance database.
The following requests must be executed to make this happen:
A user WITH GRANT OPTION must execute the following GRANT request:
GRANT GLOP ON finance TO finance;
User finance must then execute the following requests:
CREATE GLOP SET sales;
CALL DBCExtension.GLOP_Add('sales', … );
GRANT GLOP MEMBER ON finance.sales TO finance;
User Joe creates the function in the finance database. Joe must first be granted the privilege to create the UDF in the finance database by someone with the privileges to enable him to do that:
CREATE FUNCTION finance.sales_bonus( … )
RETURNS DECIMAL(6,2)
LANGUAGE C
MEMBER OF GLOP SET finance.sales
PARAMETER STYLE SQL
EXTERNAL;
Related Topics
See
“REVOKE (SQL Form)” on page 107 for information about revoking privileges granted
by the SQL form of GRANT.
82 SQL Data Control Language
GRANT CONNECT THROUGH
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Purpose
Grants the privilege to connect as a proxy permanent or proxy application user through the specified trusted user, storing the information in DBC.ConnectRulesTbl.
The statement grants the specified trusted user the privilege to:
•
Connect as the specified permanent or application user.
•
Set roles for the specified permanent or application user.
The specified trusted user is granted the privilege to assert the identity of the proxy user names specified in its defining SET QUERY_BAND request (see “SET QUERY_BAND” in SQL Data
Definition Language).
Syntax
GRANT CONNECT THROUGH
A trusted_user_name
TO
,
25 application_user_name
PERMANENT
WITH ROLE
,
25 permanent_user_name
,
role_name
WITH ROLE
15
,
role_name
15
WITHOUT ROLE where:
Syntax element …
trusted_user_name
;
1101A54
Specifies …
the name of the user receiving the CONNECT THROUGH privilege.
trusted_user_name must be the name of a permanent user who is already defined in Teradata Database, but cannot be user DBC.
This grants the specified trusted user the privilege to assert the identity of the specified proxy user names.
Note that trusted_user_name should not identify an end user. Its intent is to identify a middle-tier application such as a CRM application or
Viewpoint.
A
SQL Data Control Language 83
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Syntax element … Specifies …
application_user_name
the name of an application user to whom the proxy logon privilege is to be granted through trusted_user_name.
Application user names can be specified any time that creating a permanent user for every end user of a middle tier application would not be manageable.
Application user names are not defined in Teradata Database, but they must follow Teradata object naming conventions. An application user name can be anything that represents the client connecting to the middle tier, such as a client name or an ATM identifier.
application_user_name must be unique for the specified
trusted_user_name (see
“Application Proxy Users” on page 88 ).
You can specify a maximum of 25 application user names per GRANT
CONNECT THROUGH request, but there is no limit to the number of application user names that can be granted logon privileges to a trusted user.
The system adds the names you specify to the CONNECT THROUGH privileges for trusted_user_name.
Note that you must specify at least one role in the WITH ROLE clause for each application proxy user that you specify.
permanent_user_name
the name of a permanent user to whom the proxy logon privilege is to be granted through trusted_user_name.
permanent_user_name must be the name of a permanent Teradata
Database, but cannot be user DBC.
permanent_user_name must be unique for the specified
trusted_user_name (see
“Permanent Proxy Users” on page 88 ).
You can specify a maximum of 25 names per GRANT CONNECT
THROUGH request, but there is no limit to the number of permanent user names that can be granted logon privileges to a trusted user.
The system adds the names you specify to the CONNECT THROUGH privileges for trusted_user_name.
84 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Syntax element …
WITH ROLE
role_name
WITHOUT ROLE
Specifies …
a set of role names to be assigned to the proxy connection.
The string you specify for role_name must be the name of an internal role that is already defined in Teradata Database.
a
In this context, ALL, NONE, and NULL are not valid role names.
You must specify at least one role name for application proxy users, while you can specify WITHOUT ROLE for permanent proxy users.
You can specify a maximum of 15 role names per proxy user. Unlike the maxima for permanent and application user names, this is an absolute maximum per proxy user, not a per request maximum.
If a CONNECT THROUGH privilege already exists for the specified
trusted_user:permanent_user or trusted_user:application_user name pair, the system adds the roles you specify to the existing CONNECT
THROUGH privilege.
Note that changes to a CONNECT THROUGH privilege are effective immediately, so the next request submitted in a proxy connection following a change to a CONNECT THROUGH privilege picks up the new privilege definition.
Be aware that when roles are dropped, they are removed from the
CONNECT THROUGH privilege definition, so a rule can be left with no roles defined for it. When proxy users who have privileges that were set with the WITH ROLE clause, but later have those roles dropped, Teradata
Database grants them PUBLIC privileges only.
If the addition of new roles causes the number of roles assigned to the privilege to exceed 15, the request aborts and the system returns an error to the requestor. If this happens, you can submit an appropriate REVOKE
CONNECT request to remove one or more roles from the privilege. See
“REVOKE CONNECT THROUGH” on page 124
for information about how to use this statement.
either by default or when the proxy connection sets PROXYROLE=ALL, the system activates all of the role names specified in the WITH ROLE clause.
If a proxy connection specifies PROXYROLE=role_name, the specified role name must be one of the roles specified by the WITH ROLE clause of the current request. Teradata Database then sets the role for the proxy connection to this role.
Note that you cannot specify either WITH ROLE NONE or WITH ROLE
NULL.
to assign the privileges and roles of the specified permanent user to the
CONNECT THROUGH privilege.
You cannot specify the WITHOUT ROLE option for application users. a. An internal role is a role that is managed by Teradata Database, as opposed to an external role, which is directory-managed. See “CREATE ROLE” in SQL Data Definition Language.
ANSI Compliance
GRANT CONNECT THROUGH is a Teradata extension to the ANSI SQL:2008 standard.
SQL Data Control Language 85
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Required Privileges
You must have the CTCONTROL privilege (see “CTCONTROL Privilege” on page 65
) to perform a GRANT CONNECT THROUGH request.
You must also have the WITH ADMIN OPTION privilege on each of the roles specified in the
WITH ROLE clause of the request.
You must have the DROP USER privilege on each of the users specified as PERMANENT proxy users.
About the GRANT CONNECT Privilege
The following facts and rules apply to Teradata trusted sessions.
•
Do not use trusted sessions with applications that permit end users to submit or modify
SQL requests sent to Teradata Database.
•
The GRANT CONNECT THROUGH statement is a special version of the SQL form of the
GRANT statement (see “GRANT (SQL Form)” on page 41
). Its purpose is to grant the
CONNECT THROUGH privilege to the specified permanent user or application user through the specified trusted user.
These terms are defined as follows:
Term Definition
Application user The name of an application user to which the GRANT CONNECT proxy logon privilege is to be granted.
Application user names are not defined in Teradata Database, but they must follow Teradata object naming conventions.
You can specify up to 25 names in a single grant request. The specified names are then added to the grant privileges for the specified trusted user.
There is no limit to the number of application user names that can be granted logon privileges to a single trusted user.
Permanent user A user who is defined to Teradata Database.
In a GRANT CONNECT THROUGH request, this is the name of a user to whom the proxy logon privilege is to be granted.
There is no limit to the number of permanent users who can be granted logon privileges to a trusted user.
Trusted user A permanent user, previously defined to Teradata Database, who receives the
CONNECT THROUGH privilege by means of a GRANT CONNECT
THROUGH request.
This grants the trusted user the ability to assert the identity of the proxy user specified in the GRANT CONNECT THROUGH request.
•
Application and permanent users are collectively referred to as proxy users.
A proxy user is any user who connects to Teradata Database using the session of a trusted user.
86 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
•
A proxy connection is a connection to Teradata Database in which the user validated for privileges and logging is a proxy user who uses the privileges that are assigned to it. All other session-level attributes are those set for the trusted user such as the user name that actually logged onto Teradata Database, the account name, and spool and temporary space allocations.
•
Performance management APIs such as MonitorSession and AbortSession identify sessions by their trusted user name.
•
The system enforces Teradata Active System Management rules for trusted users, but not for proxy users.
•
A session has a value for each of the following columns. The same values are used for the session whether it has a proxy connection or not.
•
UserName
•
UserId
•
Account
•
Role
•
Profile
•
DefaultDatabase
•
TimeZone
•
DateForm
•
CharType
•
Collation
•
Transaction Isolation Level
•
UDF Function Trace
•
Replication Override
•
ProxyUser
•
ProxyUserId
•
ProxyRole
•
ProxyRoleId
WHEN the proxy user is … THEN the creator of all objects created in a proxy connection is the …
a permanent user permanent user.
an application user trusted user.
•
The following built-in functions return information about the proxy connection-related session values. See SQL Functions, Operators, Expressions, and Predicates for details.
•
USER returns the name of the trusted user for the session.
•
CURRENT_USER returns the proxy user name if the user is in a proxy connection; otherwise, CURRENT_USER returns the session user name.
•
ROLE returns the current role name for the trusted user.
•
CURRENT_ROLE returns the proxy user current role if the user is in a proxy connection; otherwise, it returns the trusted user role name.
•
If logon restrictions have been set, such as restricting logons by IP address, the system enforces them only for the trusted user logon.
Such restrictions are not enforced when a proxy username is asserted for the session.
SQL Data Control Language 87
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Application Proxy Users
An application proxy user name can be anything that represents the client connection with the middle tier application, such as a client name or an ATM identifier. The granularity of application proxy users is largely at your discretion. For example, the term ATM identifier could refer to granularities as different as an identifier for an individual ATM in an ATM network or an identifier for an individual user of any of the ATMs in the network.
The roles that can be active in a proxy connection are those defined in the CONNECT
THROUGH privilege at the time the proxy connection is made.
You cannot have duplicate application and permanent proxy user names for the same trusted user. For example, consider the following GRANT CONNECT THROUGH requests submitted in the order indicated:
GRANT CONNECT THROUGH msi TO sbd WITH ROLE finance_role;
GRANT CONNECT THROUGH msi TO sbd WITH ROLE hr_role;
The second request returns a duplicate proxy user name error because the application proxy user named sbd already exists as granted through trusted user msi.
You must specify at least one role in the WITH ROLE clause for each application proxy user.
The following rules apply to the roles assigned to application proxy users:
•
Only roles that are defined in the CONNECT THROUGH privilege at the time a proxy connection is made can be active in that connection.
All role names specified in the WITH ROLE clause are active in the proxy connection by default.
•
The specified roles are the only roles that can be set for the proxy connection.
•
You cannot set the current role in the proxy connection to NONE or NULL.
•
The privileges for the proxy connection are those for its active roles and PUBLIC.
Permanent Proxy Users
A permanent proxy user is an existing permanent user who is defined to Teradata Database. A
GRANT CONNECT THROUGH request validates that a permanent proxy user who is specified in that request exists in Teradata Database. The anticipated use of permanent proxy users is for intranet-type middle tier applications that, for example, might display employee pay stubs or information about available vacation time.
Teradata Database assigns the name of the permanent proxy user as the creator of any objects created while the proxy connection is in effect.
You cannot have duplicate application and permanent proxy user names for the same trusted user. For example, consider the following GRANT CONNECT THROUGH requests submitted in the order indicated:
GRANT CONNECT THROUGH crm TO PERMANENT mary;
GRANT CONNECT THROUGH crm TO mary WITH ROLE hr_role;
88 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
The second request returns a duplicate proxy user name error because the permanent proxy user named mary already exists as granted through trusted user crm.
All roles specified in a WITH ROLES clause are active in a proxy connection by default.
Note, however, that changes to a CONNECT THROUGH privilege definition are effective immediately, so the next request submitted in a proxy connection following a change to a
CONNECT THROUGH privilege uses the new definition.
Be aware that when roles are dropped, they are also removed from the CONNECT
THROUGH privilege definition, so it is possible for a rule to be left with no roles defined for it. When you drop all of the roles that were assigned to a CONNECT THROUGH privilege definition, Teradata Database grants the affected proxy users PUBLIC privileges only.
The roles that can be set for a permanent proxy user in a proxy connection are different depending on the WITH ROLES clause in the GRANT CONNECT THROUGH request, as listed in the following table:
IF you specify a …
WITH ROLE clause in your
GRANT CONNECT THROUGH request
WITHOUT ROLE clause in your
GRANT CONNECT THROUGH request
THEN …
•
all role names you specify are active in the proxy connection by default.
The roles in the WITH ROLE clause do not need to be granted directly to the user. The GRANT CONNECT
THROUGH request grants this privilege by default.
•
the specified roles are the only roles that can be set for the proxy connection.
•
setting the current role to NONE or NULL in the proxy connection is not permitted.
•
the privileges for the proxy connection are those for its active roles and PUBLIC.
•
the default role for the proxy connection is the default role defined for the permanent user.
•
the roles that can be set for the proxy connection are restricted to those granted to the user.
In this case, the role in the proxy connection can also be set to NONE or NULL.
•
the privileges for the proxy connection are those granted to the permanent user, its active roles, and PUBLIC.
Granting CONNECT THROUGH to Multiple Trusted Users
A permanent or application user can be granted CONNECT THROUGH privileges through different trusted users with different roles.
Consider the following example requests, both for an application proxy user:
GRANT CONNECT THROUGH msi TO debbieg WITH ROLE msirole;
GRANT CONNECT THROUGH tadmin TO debbieg WITH ROLE tadminrole;
SQL Data Control Language 89
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
After these requests have been successfully submitted, both the msi and tadmin trusted users have proxy connect privileges for the application user debbieg; however, when performing the respective proxy connections, each session for debbieg is set to a different role: msirole through trusted user msi and tadminrole through trusted user tadmin.
CONNECT THROUGH and Access Logging
The system logs each GRANT CONNECT THROUGH request in the access log when logging has been enabled with BEGIN LOGGING requests like the following:
BEGIN LOGGING ON EACH GRANT;
CONNECT THROUGH and Parameter Markers
Parameter markers are not supported for GRANT CONNECT THROUGH requests.
CONNECT THROUGH and User DBC
You cannot specify user DBC as either the trusted user or as a proxy user in a GRANT
CONNECT THROUGH request.
Dictionary Storage of CONNECT THROUGH Metadata
The dictionary table DBC.ConnectRulesTbl stores information on which proxy users can connect through which trusted users and what roles are available to make proxy connections.
The table contains one row for every trusted_user_name:proxy_user_name combination.
When the system processes a GRANT CONNECT THROUGH request, it writes a row to
DBC.ConnectRulesTbl for each of the following pairs that you specify:
•
Trusted user name:permanent user name
•
Trusted user name:application user name
The row persists until either you drop the trusted user or the permanent user.
To provide an audit trail for the management of the rules, the system retains the row if the privilege is revoked, but the user is not dropped. DBC.ConnectRulesTbl.GrantStatus contains a
G if the privilege is granted and an R if it is revoked.
See Data Dictionary for details about DBC.ConnectRulesTbl.
90 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Example 1
The following GRANT CONNECT THROUGH request grants the CONNECT THROUGH privilege to permanent user sbd with the assigned proxy connection role admin through trusted user viewpoint.
GRANT CONNECT THROUGH viewpoint
TO PERMANENT sbd
WITH ROLE admin;
After this request has been successfully submitted, user sbd has proxy connect privileges through the trusted user viewpoint, and whenever sbd makes a proxy connection, the system assigns him to the admin role.
Example 2: Specifying Roles for a Proxy Connection
All roles specified in the WITH ROLE clause of this example are active by default in the proxy connection.
If no ProxyRole is set for application user dg120 in the proxy connection, the active roles are
salesrole1, salesrole2, and salesrole3.
The proxy connection can be set to one role that is in the WITH ROLE clause. For example, the ProxyRole for application user dg120 can be set to salesrole1, salesrole2, or salesrole3, but no other roles are permitted.
GRANT CONNECT THROUGH dcm
TO dg120, ks392, lm190
WITH ROLE salesrole1, salesrole2, salesrole3;
Example 3: Specifying WITHOUT ROLE for a Proxy Connection
When you set a WITHOUT ROLE clause for a permanent proxy user, as the following request demonstrates, the system uses the privileges and roles granted to that permanent user, and the default proxy role is the default role defined for the proxy permanent user.
The roles that can be set for the proxy user are restricted to the roles granted to the proxy permanent user
GRANT CONNECT THROUGH trm
TO PERMANENT accting
WITHOUT ROLE;
SQL Data Control Language 91
Chapter 2: SQL Data Control Language Statement Syntax
GRANT CONNECT THROUGH
Related Topics
FOR more information on …
Revoking proxy connections
Setting query bands to enable proxy connections
Administering trusted sessions
Security issues related to trusted sessions
The dictionary attributes of trusted sessions
SEE …
“REVOKE CONNECT THROUGH” on page 124
“SET QUERY_BAND” in SQL Data Definition
Language
Database Administration
Security Administration
Data Dictionary
92 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT LOGON
GRANT LOGON
Purpose
Syntax
Does either of the following:
•
Gives specific users permission to log on to Teradata Database from one or more specific client systems.
•
Changes the current system logon defaults.
GRANT LOGON ON
,
host_id
ALL
AS DEFAULT
,
TO user_name
FROM where:
WITH NULL PASSWORD
;
1101C027
Syntax Element...
host_id
Specifies...
a mainframe channel connection or a local area network connection that is currently defined to the system by the hardware configuration data. The interface need not be operational.
The host ID for the Teradata Database console is 0. For any other connection,
host_id can be any value ranging from 1 to 1023 inclusive.
FOR this platform operating system … You can define this many host_ids per node …
UNIX
Windows
1.
multiple.
SQL Data Control Language 93
Chapter 2: SQL Data Control Language Statement Syntax
GRANT LOGON
Syntax Element...
ALL
AS DEFAULT
Specifies...
The difference exists because UNIX-based systems see all LANs as the same client on a node, while Windows-based systems do not. The limit on UNIX systems is absolute and is true irrespective of how many network adapters are configured for a given node.
As a result, if LAN host ID separation is required to support a function such as security isolation on a UNIX-based system, then some nodes must be physically connected to only one LAN and defined as, for example, host_id_1, while other nodes must be physically connected to only one other LAN, with those connections being defined under a different host ID such as host_id_2, for example.
This means that for a multisession situation on a UNIX-based system, such as a MultiLoad run, sessions can only be established on a subset of the system nodes rather than being spread across all nodes evenly. This can have a negative impact on PE and Gateway activities such as the acquisition phase of
MultiLoad.
any source through which a logon is attempted, including the Teradata
Database system console.
that the current default for the specified host_id set is to be changed, without residual conditions, as defined in this GRANT LOGON statement. A statement with AS DEFAULT has no effect on the access granted to or revoked from particular user names.
A statement that sets the default for a specific host_id takes precedence over a statement that sets the default for ALL client systems. the clause that specifies the recipient of the GRANT results.
TO
FROM
user_name
WITH NULL
PASSWORD one or more user names whose current system logon defaults are to be changed.
•
You cannot specify the name DBC as a user name in a GRANT LOGON statement. A statement that includes this name returns an error message.
•
The product of the number of host IDs times the number of user names cannot exceed 25.
to permit a logon string that has no password to be accepted from the specified client system community.
The initial default is that all logon requests must include a password. The
WITH NULL PASSWORD option, in conjunction with a TDP security exit procedure, negates that default.
This option implies that the user has been authenticated externally and not by the database. See Security Administration for details.
ANSI Compliance
GRANT LOGON is an extension to the ANSI SQL:2008 standard.
94 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT LOGON
Required Privileges
You must have the EXECUTE privilege on the DBC.LogonRule macro to perform GRANT
LOGON.
System Privilege Checks
A statement that includes the AS DEFAULT option has no effect on the logon access granted to or revoked from specific user names. A user named in a GRANT LOGON statement can always access the applicable client system even if that client has a default of REVOKE, and a user named in a REVOKE LOGON statement cannot access the applicable client system even if that client has a default of GRANT.
When a GRANT LOGON statement is submitted, the system checks that the requesting user has EXECUTE privilege on the system macro associated with that statement. However, no checks are made on whether the user names defined in the statement apply to users owned by the requesting user. If the submitted statement cannot be verified because, for example, it specifies a non-valid user name or an invalid host ID, no action is taken on the statement.
GRANT LOGON for One or More User Names
When a GRANT LOGON statement is processed for one or more user names, a logon control record is created for each user_name/host_ID pair specified. Any existing control record for a particular user_name/host_ID pair is replaced. The logon control record created for a particular user name persists until that user is dropped (see “DROP USER” in SQL Data
Definition Language).
If No Logon Control Record for a User Name
If there is no logon control record for a specific user name, access to Teradata Database under that name is governed by the current default for the host ID through which the logon is entered.
Logging On as User DBC
Logging onto Teradata Database as user DBC requires a password. If the submitted password is correct, the logon is accepted regardless of the current default for the applicable host ID.
This prevents any opportunity to lock out all client systems from Teradata Database.
You cannot grant logon to user name DBC.
Logging On Without a Password
When Teradata Database is connected to multiple client systems, the initial default is that logon permission is granted to all users from all client systems, and that all logons must include a password.
SQL Data Control Language 95
Chapter 2: SQL Data Control Language Statement Syntax
GRANT LOGON
Logging on without a password requires the following things:
•
A GRANT LOGON statement that includes the WITH NULL PASSWORD option must be performed for the defined user name or must be the default for the host ID.
•
A security exit installed in the client system must acknowledge that the logon string for this user is valid without a password.
FOR this client type …
Channel-attached
The security exit is installed in one of these client applications …
•
TDP
•
CLI
CLI Network-attached
Logging On Using External Authentication
External authentication permits a user to log onto a computer one time and, for the duration of that logon, to be able to access a Teradata Database without providing a user name, password, or account name. You do this by granting the user logon privileges with a null password.
See Security Administration, Database Administration, and Utilities for details about external authentication.
The following procedure creates a Teradata Database user who can log onto the system through a gateway that does not have the Append Domain Name option set using the
Gtwcontrol utility. This user is already defined to Windows as user rhh.
1
2
3
Create user rhh using the following CREATE USER statement.
CREATE USER rhh AS
PERM = 10000000,
PASSWORD = rhh;
Grant user rhh the following logon privileges using the GRANT LOGON statement.
GRANT LOGON ON ALL
TO rhh
WITH NULL PASSWORD;
End of procedure.
96 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
GRANT LOGON
The following procedure creates a Teradata Database user who can log onto the system through a gateway that has Append Domain Name set. This user is already defined to
Windows as user rhh and her account is in the esw2kdev domain.
1
2
3
Create user rhh using the following CREATE USER statement.
CREATE USER "rhh@esw2kdev" AS
PERM = 10000000,
PASSWORD = rhh;
Grant user rhh the following logon privileges using the GRANT LOGON statement.
GRANT LOGON ON ALL
TO "rhh@esw2kdev"
WITH NULL PASSWORD;
End of procedure.
Related Topics
See
for information about revoking logon privileges.
SQL Data Control Language 97
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE
REVOKE
Purpose
REVOKE rescinds explicit privileges from one or more users, proxy users, databases, or roles.
The privileges might have been conferred either automatically or by a previous GRANT statement.
ANSI Compliance
REVOKE (Role Form) and REVOKE (SQL Form) are ANSI SQL:2008-compliant. The other forms of REVOKE are extensions to the ANSI SQL:2008 standard.
Revocation Limits
Implicit privileges are governed by ownership and cannot be revoked. You can affect implicit
privileges by using the GIVE statement to change ownership (see “GIVE” on page 30 for more
information).
Forms of REVOKE
REVOKE has five forms that differ both in function and in syntax. These forms are documented as follows:
•
“REVOKE (Monitor Form)” on page 100
•
“REVOKE (Role Form)” on page 104
•
“REVOKE (SQL Form)” on page 107
•
“REVOKE CONNECT THROUGH” on page 124
•
Types of Privileges REVOKE Can Remove
The REVOKE statements operate on explicit privileges recorded in the DBC.AccessRights table.
This means that you cannot revoke implicit privileges because those privileges are not stored in DBC.AccessRights.
Only those explicit privileges that have been granted automatically or explicitly can be revoked.
In most cases, implicit privileges only permit the user holding them to grant them to others, not to perform the SQL statements that correspond to those privileges. Generally, you must have explicit privileges to perform access protected SQL statements. The main exceptions to this rule are privileges on views, macros, and stored procedures. See
“Implicit Privileges” on page 21
for more information.
98 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE
REVOKE (SQL Form) and REVOKE (MONITOR Form) Have Different
Functions
The SQL and MONITOR forms of REVOKE perform separate functions.
To revoke all privileges, including MONITOR, for a user you must perform both of the following statements:
REVOKE ALL PRIVILEGES ON object
FROM user;
REVOKE MONITOR PRIVILEGES
FROM user;
Both statements assume that you have the appropriate privileges, either implicitly or explicitly,
WITH GRANT OPTION.
SQL Data Control Language 99
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Monitor Form)
REVOKE (Monitor Form)
Purpose
Syntax
Revokes system-wide performance monitoring privileges.
REVOKE
GRANT OPTION FOR
A
TO
FROM
MONITOR
PRIVILEGES
BUT NOT
,
,
monitor_privilege monitor_privilege
,
user_name
ALL
PUBLIC where:
A
1101A214
Syntax Element … Specifies...
GRANT OPTION FOR that only the grant authority is removed from the specified privileges for the specified grantees.
REVOKE GRANT OPTION FOR revokes the privilege of the recipient to grant, but does not revoke the stated privileges themselves.
MONITOR
PRIVILEGES to revoke from the specified user all privileges, except MONITOR, that can be granted on the specified object, and that are possessed WITH
GRANT OPTION by the user executing the REVOKE.
To revoke all privileges for a user, including MONITOR, you must perform at least two statements as follows:
REVOKE ALL PRIVILEGES ON object
FROM user_name;
REVOKE MONITOR PRIVILEGES
FROM user_name;
ALL PRIVILEGES means all database privileges.
100 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Monitor Form)
Syntax Element … Specifies...
If you specify the ALL PRIVILEGES option, then only the privileges possessed with grant authority are revoked from the grantee.
MONITOR PRIVILEGES indicates all monitoring privileges.
The ANSI SQL:2008 standard requires ALL to be followed by
PRIVILEGES.
MONITOR BUT NOT to revoke all of the MONITOR privileges except those specified by
monitor_privilege.
monitor_privilege
the monitoring privileges that are to be revoked.
You can specify as many of the following privileges as you wish, separated by commas.
ALL
user_name
PUBLIC
Privilege Description
ABORTSESSION Aborts any outstanding request or ongoing transaction of one or more Teradata Database sessions and, optionally, logs off the sessions.
CTCONTROL Disables a user from executing a GRANT
CONNECT THROUGH or REVOKE
CONNECT THROUGH request.
MONRESOURCE Gathers information on the performance and availability of each AMP and PE.
MONSESSION Gathers information about logged on sessions and overall system usage on a session-by-session basis.
SETRESRATE
SETSESSRATE
Sets the frequency at which processor resource usage data is updated in the system.
Sets the frequency at which session-level performance data is updated in the system.
Any combination of privileges can be revoked by a user who has those privileges with GRANT option.
that the monitoring privileges are to be to revoked from the named database or user, and every database or user owned by that database or user now and in the future.
ALL user_name is a Teradata extension to the ANSI SQL:2008 standard.
the database or user from whom monitoring privileges are to be revoked.
You can specify up to 25 names.
that the monitoring privileges are to be revoked from all currently defined and future users of Teradata Database.
ALL DBC is equivalent to PUBLIC.
SQL Data Control Language 101
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Monitor Form)
ANSI Compliance
The monitor form of REVOKE is an extension to the ANSI SQL:2008 standard.
Required Privileges
For REVOKE (Monitor), the user submitting a REVOKE statement must have all the privileges that are to be revoked with GRANT option.
Privileges Revoked Immediately
REVOKE MONITOR takes effect immediately when the revoked user issues his next statement.
REVOKE (SQL Form) and REVOKE (Monitor Form) Differences
The SQL and MONITOR forms of REVOKE are separate statements. To revoke all privileges for a user, including MONITOR, the grantor must perform both of the following statements.
REVOKE ALL PRIVILEGES ON object
FROM user_name;
REVOKE MONITOR PRIVILEGES
FROM user_name;
Rules for Using REVOKE (Monitor Form)
These keywords …
ALL PRIVILEGES
MONITOR PRIVILEGES
Mean that all …
database-related privileges are affected.
system monitoring privileges are affected.
If you violate either one of the following restrictions, a failure response occurs.
This action is not valid …
Specify an ON object clause
Not to specify an ON object clause
For this type of REVOKE statement …
REVOKE MONITOR.
any other type.
The result of performing a REVOKE statement takes effect as soon as the recipient issues his next statement.
Revokable Privileges
Implicit privileges cannot be revoked. See “Revocation Limits” on page 98 for more
information.
102 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Monitor Form)
Revoking the GRANT OPTION for a privilege from a user immediately revokes the privilege of that user to grant that privilege. However, it does not affect privileges that have already been granted by that user to others.
IF a …
user receives the same privilege from two or more grantors
The user who revokes a privilege from another need not be the grantor of that privilege.
privilege that was granted to ALL user_name is revoked from user_name.
THEN …
any grantor with the necessary privileges can revoke that privilege from the user and from other grantees.
the privilege is not granted automatically to future users owned by user_name.
Example 1
This statement pair revokes all SQL privileges on the accounting database and all monitor privileges on the system from user df2:
REVOKE ALL PRIVILEGES ON accounting
FROM df2;
REVOKE MONITOR PRIVILEGES
FROM df2;
This example assumes that the revoker has the necessary privileges either implicitly or explicitly WITH GRANT OPTION.
Example 2
This statement revokes the ABORTSESSION, MONSESSION, and SETSESSRATE monitor privileges from user pls:
REVOKE ABORTSESSION, MONSESSION, SETSESSRATE FROM pls;
This example assumes that the revoker has the necessary privileges either implicitly or explicitly WITH GRANT OPTION.
Related Topics
See
“GRANT (Monitor Form)” on page 34 for information about granting monitor privileges.
SQL Data Control Language 103
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Role Form)
REVOKE (Role Form)
Purpose
Revokes a role from users or other roles.
Syntax
REVOKE
ADMIN OPTION FOR
, role_name TO
FROM
, user_name role_name
;
KZ01a009 where:
Syntax Element … Specifies …
ADMIN OPTION FOR that the roles and users who were granted this role lose the privilege to use
GRANT, REVOKE, and DROP ROLE statements to administer the specified role.
If you do not specify ADMIN OPTION FOR in the REVOKE request, the system revokes the specified role from the roles or users to which it was granted.
role_name
one or more comma-separated names of roles that are being revoked.
You can specify a maximum of 25 names per REVOKE request.
The system ignores duplicate role names.
TO
FROM
user_name role_name
the names of roles or users or both from which the role or the ability to administer the role is being revoked.
The system does not return errors for users or roles that were not previously granted the specified role.
The TO keyword is a Teradata extension to ANSI SQL:2008.
ANSI Compliance
REVOKE (Role Form) is ANSI SQL:2008-compliant.
104 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Role Form)
Required Privileges
To revoke a role, you must have the WITH ADMIN OPTION privilege on it. The following users can revoke role membership:
•
User DBC.
•
A user who was granted the specified role WITH ADMIN OPTION.
A role is automatically granted to the creator of the role WITH ADMIN OPTION.
•
A user who has an active role to which the specified role was granted WITH ADMIN
OPTION. An active role can be either a current role or a nested role of a current role.
Revoking Roles
Roles define privileges on database objects. A user who activates a role inherits all the privileges for the role and its nested roles. A user can only activate a role that has been granted to that user.
Users can undergo role changes within their organization. An administrator can revoke a role when users no longer require access to the objects that the role has privileges to. An administrator can also revoke the WITH ADMIN OPTION privilege on a role when users no longer require the privilege to grant the role to users or other roles.
Authorized users can revoke the WITH ADMIN OPTION privilege on a role from the creator of the role.
Effects of Revoking a Role
The effect of revoking a role is immediate. Users who are logged on with the revoked role as the current role or a nested role of the current role lose the privileges that the role defines.
Users who have a default role set to the revoked role do not receive errors or warnings the next time they log on. However, the system does not use the obsolete default role for privilege validation. If the role is again granted to users, the default role again becomes the current role the next time users log on.
Example
If user marks gets a promotion from sales to management, the DBA can use the following statements to revoke the sales role and grant the management role:
REVOKE sales
FROM marks;
GRANT management
TO marks;
SQL Data Control Language 105
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (Role Form)
Related Topics
FOR more information on …
granting roles to users and other roles assigning default roles to users changing the current role for a session
SEE …
“GRANT (Role Form)” on page 38
•
“CREATE USER” in SQL Data Definition
Language
•
“MODIFY USER” in SQL Data Definition
Language
“SET ROLE” in SQL Data Definition Language
106 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
REVOKE (SQL Form)
Purpose
Revokes one or more explicit privileges on a database, user, table, view, stored procedure, user-defined function, or macro from a role, group of roles, user, or group of users or removes the GRANT option from explicit privileges.
Syntax
REVOKE
A
B
ON a
GRANT OPTION FOR
database_name user_name role_name
PUBLIC
database_name.
user_name.
object_name object_name
PROCEDURE
database_name.
user_name.
ALL
PRIVILEGES
,
privilege
ALL BUT
,
role_privilege
,
profile_privilege procedure_name
SPECIFIC FUNCTION
FUNCTION
database_name.
user_name.
specific_function_name database_name.
user_name.
function_name
(
parameter_name
,
TYPE
UDT_name
SYSUDTLIB.
TO
FROM
,
user_name
ALL
PUBLIC
,
role_name database_name.
user_name.
data type
) a
A
B
1101V061
SQL Data Control Language 107
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
108
A
Data Type
INTEGER
SMALLINT
BIGINT
BYTEINT
DATE
TIME
TIMESTAMP
( fractional_seconds_precision ) WITH TIMEZONE
INTERVAL YEAR
( precision ) TO MONTH
INTERVAL MONTH
( precision )
INTERVAL DAY
( precision
)
TO HOUR
MINUTE
SECOND
( fractional_seconds_precision )
INTERVAL HOUR
( precision )
TO MINUTE
SECOND
( fractional_seconds_precision )
INTERVAL MINUTE
( precision )
TO SECOND
( fractional_seconds_precision )
INTERVAL SECOND
( precision
, fractional_seconds_precision
PERIOD(DATE)
PERIOD(TIME
PERIOD(TIMESTAMP ( precision ) WITH TIMEZONE
REAL
DOUBLE PRECISION
FLOAT
( integer )
DECIMAL
NUMERIC ( integer
)
, integer
)
)
B
1101A535
SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
A B
CHAR
BYTE
GRAPHIC
VARCHAR
CHAR VARYING
VARBYTE
VARGRAPHIC
LONG VARCHAR
LONG VARGRAPHIC
( integer )
( integer )
BINARY LARGE OBJECT
BLOB
CHARACTER LARGE OBJECT
CLOB
(
integer
SYSUDTLIB.
UDT_name
ST_Geometry
MBR
G
K
M where:
Syntax Element …
GRANT OPTION FOR
(
1101A536
Specifies …
that only the GRANT authority is removed from the specified privileges for the specified grantees for the corresponding explicit privileges they have.
REVOKE GRANT OPTION FOR revokes the ability to grant the specified privileges to others, but does not revoke the explicit privileges themselves from the specified users or roles.
This option does not apply to grantees that are roles.
SQL Data Control Language 109
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Syntax Element …
ALL [PRIVILEGES]
ALL BUT
privilege
Specifies …
to revoke from the specified user or role all explicitly granted non-MONITOR database, but not table, privileges that can be granted on the specified object, and that are held, either implicitly or explicitly, WITH GRANT OPTION by the user executing the
REVOKE.
This means that REVOKE ALL does not revoke the INDEX and
REFERENCES privileges. To revoke these privileges, you must do so explicitly.
To revoke all explicit database privileges for a user, including
MONITOR, the revoker must perform at least two statements, shown as follows:
REVOKE ALL PRIVILEGES ON object
FROM user_name;
REVOKE MONITOR PRIVILEGES
FROM user_name;
ALL PRIVILEGES means all explicit database privileges.
If you specify ALL PRIVILEGES, then only the explicit privileges held with grant authority are revoked from the grantee.
ANSI SQL requires ALL to be followed by the keyword
PRIVILEGES.
to revoke all explicit database privileges from the specified user, database, or role, except those listed, that can be granted on the specified object and that are held, either implicitly or explicitly,
WITH GRANT OPTION by the user performing the REVOKE statement.
one of the privileges listed in “Supported Privileges” on page 114
.
INSERT, REFERENCES, SELECT, and UPDATE have separate table-
and column-level options. See “GRANT (SQL Form)” on page 41
.
You cannot grant the UPDATE privilege on a GENERATED ALWAYS identity column.
The ANSI SQL:2008 standard does not support REVOKE on a database or user, or ALL BUT. These are Teradata extensions to the
ANSI SQL-2008 standard.
You can specify any combination of privileges; however, the user submitting the statement must itself have all of the specified privileges, either implicitly or explicitly, WITH GRANT OPTION.
If DATABASE, FUNCTION, MACRO, PROCEDURE, PROFILE,
ROLE, TABLE, TRIGGER, USER, or VIEW is specified without
CREATE or DROP, both CREATE and DROP are revoked.
If you specify CHECKPOINT, then the privilege is revoked both for the SQL statement and for the HUT commands DUMP and
RESTORE.
If you specify either DUMP or RESTORE individually, then the system revokes the privilege to perform the corresponding HUT command only.
110 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Syntax Element …
role_privilege profile_privilege
database_name | user_name |
role_name | PUBLIC
database_name.
object_name |
user_name.object_name
Specifies …
If you specify RESTORE, then the system also revokes the privileges to perform the HUT commands ROLLBACK, ROLLFORWARD, and
DELETE JOURNAL.
You cannot revoke privileges on a trigger, only on its containing database or its subject table.
one of the following privileges:
•
CREATE ROLE
•
DROP ROLE
•
ROLE a
Role privileges can only be revoked from a set of users or a role. They cannot be revoked from an object.
Use the ROLE privilege to revoke the CREATE ROLE and DROP
ROLE privileges.
one of the following privileges:
•
CREATE PROFILE
•
DROP PROFILE
•
PROFILE b
Profile privileges can only be revoked from a set of users or a role.
They cannot be revoked from an object.
Use the PROFILE privilege to revoke the CREATE PROFILE and
DROP PROFILE privileges.
the name of a database, user, role or PUBLIC on which the explicitly granted privileges are to be revoked. All objects contained by this database or user space are affected. the name of the immediately owning database or user and the name of the object (table, view, stored procedure, join index, or macro) on which explicitly granted privileges are being revoked.
Only the specified object, and not all objects in the database or user space, is affected by revoking the privilege set.
SQL Data Control Language 111
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Syntax Element …
object_name
Specifies …
the name of the table, view, join index, stored procedure, function or macro from which explicitly granted privileges to be revoked.
You should always qualify object names when revoking privileges because the system checks database names before it checks object names.
IF … THEN the system …
the object name is not qualified assumes it is a database name.
the object name is not qualified and no database having that name is found neither a database nor an object is found assumes it is an object within the current database.
returns an error to the requestor.
PROCEDURE
[database_name | user_name]
procedure_name
SPECIFIC FUNCTION
[database_name | user_name]
specific_function_name
FUNCTION [database_name
| user_name]
function_name
[parameter_name]
parameter_data_type
the name of the procedure from which privileges are to be revoked.
The procedure name can be qualified by its containing database or user when necessary.
the specific name of the function from which privileges are to be revoked.
The specific function name can be qualified by its containing database or user when necessary.
the name of the function from which privileges are to be revoked.
The function name can be qualified by its containing database or user when necessary.
a parenthetical comma-separated list of data types and optional parameter names for the variables to be passed to the function. This is used to uniquely identify overdetermined function names.
BLOB and CLOB types must be represented by a locator (see SQL
Data Manipulation Language for a description of locators). Teradata
Database does not support in-memory LOB parameters: an AS
LOCATOR phrase must be specified for each LOB parameter and return value.
You must specify opening and closing parentheses even if no parameters are passed to the function.
The data type associated with each parameter is the type of the parameter or returned value. All Teradata Database data types are valid. Character data can also specify a CHARACTER SET clause.
112 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Syntax Element …
TYPE [SYSUDTLIB.]
UDT_name
Specifies …
the name of a UDT on which a privilege set is to be revoked.
The various TYPE privileges can be revoked as follows:
THIS privilege …
UDTMETHOD
UDTTYPE
UDTUSAGE
CAN be revoked from …
SYSUDTLIB database.
•
SYSUDTLIB database.
•
TYPE.
TO
FROM
ALL user_name
PUBLIC
database_name | user_name
role_name
the recipient of the REVOKE statement action, which can be a set of users, ALL users, a role, or PUBLIC.
You can specify a maximum of 25 names per REVOKE request.
For compatibility, ANSI SQL requires you to specify FROM rather than TO.
the database or user from whom explicit privileges are revoked. You can specify up to 25 names.
ALL user_name specifies that the privileges are to be granted to or revoked from the named database or user, and every database or user owned by that database or user now and in the future.
If you do not specify ALL user_name, then the revocation does not cascade through the hierarchy.
ALL user_name is a Teradata extension to ANSI SQL.
that the explicit privileges are to be revoked from all currently defined Teradata Database users and are not to be granted to future users.
ALL DBC is equivalent to PUBLIC.
the containing database or user for role_name if something other than the current database or user.
the name of a role from which privileges are revoked.
You can specify up to 25 role names.
a. ROLE is not a separate privilege. It is shorthand for both CREATE ROLE and DROP ROLE.
b. PROFILE is not a separate privilege. It is shorthand for both CREATE PROFILE and DROP PROFILE.
ANSI Compliance
REVOKE is ANSI SQL:2008-compliant with extensions.
SQL Data Control Language 113
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Supported Privileges
Teradata Database supports the privileges listed in the following list:
•
ABORT SESSION
•
ALTER EXTERNAL
PROCEDURE
•
ALTER FUNCTION
•
ALTER PROCEDURE
•
AUTHORIZATION
•
CHECKPOINT
•
CREATE AUTHORIZATION
•
CREATE DATABASE
•
CREATE EXTERNAL
PROCEDURE
•
CREATE FUNCTION
•
CREATE GLOP
•
CREATE MACRO
•
CREATE OWNER
PROCEDURE
•
CREATE PROCEDURE
•
CREATE PROFILE
•
CREATE ROLE
•
CREATE TABLE
•
CREATE TRIGGER
•
CREATE USER
•
CREATE VIEW
•
CTCONTROL
•
DATABASE
•
DROP
•
DROP AUTHORIZATION
•
DROP DATABASE
•
DROP FUNCTION
•
DROP GLOP
•
DROP MACRO
•
DROP PROCEDURE
•
DROP PROFILE
•
DROP ROLE
•
DROP TABLE
•
DROP TRIGGER
•
DROP USER
•
DROP VIEW
•
DUMP
•
EXECUTE
•
EXECUTE FUNCTION
•
EXECUTE PROCEDURE
•
FUNCTION
•
GLOP
•
GLOP MEMBER
•
INDEX
•
INSERT [(column_list)]
•
MACRO
•
MONITOR RESOURCE
•
MONITOR SESSION
•
PROCEDURE
•
REFERENCES [(column_list)]
•
REFERENCES ALL BUT …
[(column_list)]
•
REPLCONTROL
•
RESTORE
•
SELECT [(column_list)]
•
SET RESOURCE RATE
•
SET SESSION RATE
•
SHOW
•
STATISTICS
•
TABLE
•
TRIGGER
•
UDTMETHOD
•
UDTTYPE
•
UDTUSAGE
•
UPDATE [(column_list)]
•
UPDATE ALL BUT …
[(column_list)]
•
USER
•
VIEW
The term [(column_list)] following a privilege indicates a parenthetically enclosed set of optional comma-separated column names from which the privilege is to be revoked.
Required Privileges
To revoke a privilege, you must first have the privileges to grant it. You must either own the database object, or someone must first grant the privilege, either automatically or explicitly, to you, either directly or by means of a role, using WITH GRANT OPTION.
If the object is a view or macro, the submitting user also must have the applicable privileges,
WITH GRANT OPTION, on the objects referenced by the view or macro.
Privilege Abbreviations
See Data Dictionary for a complete list of privileges and their abbreviations as maintained in
DBC.AccessRights. You cannot use these abbreviations in a REVOKE (SQL Form) request.
Instead, you must specify the complete privilege name.
114 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Rules for privileges Keywords
The following rules apply to using the privileges valid for the REVOKE (SQL Form) statement
(see “REVOKE (SQL Form)” on page 107 ):
•
You can specify any combination of privileges appropriate for the corresponding database objects. However, the user submitting the statement must, itself, have those privileges, either implicitly or explicitly and WITH GRANT OPTION, on all of the specified objects.
•
The CHECKPOINT privilege applies to performing both the SQL statement and the Host
Utilities (HUT) Archive/Recovery commands DUMP and RESTORE.
The DUMP and RESTORE privileges refer to the corresponding HUT command performed on the specified object.
RESTORE also refers to execution of the following HUT commands:
•
ROLLBACK
•
ROLLFORWARD
•
DELETE JOURNAL
If you specify CHECKPOINT, then the system revokes the privilege for the SQL statement and for both the Archive/Recovery utility commands DUMP and RESTORE.
The DUMP and RESTORE privileges refer individually to the corresponding HUT commands performed on the specified object.
•
CREATE DATABASE, FUNCTION, MACRO, PROCEDURE, TABLE, VIEW, or USER, and DROP DATABASE or USER are allowed only on databases or users.
•
DROP TABLE includes ALTER TABLE.
•
DROP MACRO, DROP PROCEDURE, or DROP VIEW include REPLACE MACRO,
REPLACE PROCEDURE, or REPLACE VIEW, respectively.
•
Only DROP and EXECUTE are allowed on specified stored procedures, user-defined functions, or macros.
If the object is a user-defined function or stored procedure, then you must precede its name with the appropriate keyword (either FUNCTION or PROCEDURE), respectively.
If you do not specify one of those keywords, then the system assumes that the specified object name references a macro. If no macro by that name exists, then the statement aborts and returns an error.
•
Only ALTER FUNCTION, CREATE FUNCTION, DROP FUNCTION, EXECUTE
FUNCTION, and FUNCTION are allowed on user-defined functions.
•
Only ALTER PROCEDURE, DROP PROCEDURE, and EXECUTE PROCEDURE are allowed on stored procedures.
•
DUMP, RESTORE, and CHECKPOINT are not allowed on views.
•
If you revoke RESTORE, then the privilege to perform the following utility commands is also revoked:
•
ROLLBACK
•
ROLLFORWARD
•
DELETE JOURNAL.
SQL Data Control Language 115
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
•
DATABASE, FUNCTION, JOIN INDEX, MACRO, PROCEDURE, PROFILE, ROLE,
TABLE, VIEW, and USER confer both CREATE and DROP privileges on the respective database objects.
If the DATABASE, FUNCTION, GLOP, JOIN INDEX, MACRO, PROCEDURE, PROFILE,
ROLE, TABLE, USER, or VIEW keyword is specified without CREATE or DROP, then both CREATE and DROP are revoked.
•
ANSI SQL:2008 supports the following privileges only:
•
DELETE
•
EXECUTE
•
INSERT
•
REFERENCES
•
SELECT
•
TRIGGER
•
UPDATE
The other privileges documented here are Teradata extensions to the ANSI SQL:2008 standard.
•
In most cases, the privilege keyword agrees with the keyword of a Teradata Database SQL statement. However, the following operations do not correspond to any SQL statements:
•
DATABASE
•
DUMP
•
MACRO
•
PROCEDURE
•
RESTORE
•
TABLE
•
USER
•
VIEW
•
INSERT, REFERENCES, SELECT, and UPDATE have both table- and column-level options.
•
You can revoke CREATE ROLE, DROP ROLE, CREATE PROFILE, and DROP PROFILE privileges from users only, not from roles or databases.
•
CREATE ROLE, DROP ROLE, CREATE PROFILE, and DROP PROFILE are system privileges; you can revoke the privileges from a user, but not on a specific object.
•
With respect to collecting or dropping statistics, the STATISTICS privilege has the same effect as either INDEX or DROP TABLE.
Privileges Are Revoked Immediately
REVOKE takes effect immediately when the revoked user issues his next statement.
Privileges Must Be Revoked At The Same Level As They Were Granted
The rows in DBC.AccessRights correlate privileges to the level in the system space hierarchy at which they were created. As a result, it is possible to submit a valid REVOKE statement that does not revoke the privileges you specify because the revocation was not requested at the correct hierarchical level.
116 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
For example, if privileges on an object were granted at the database or user level, and you later submit a REVOKE statement to rescind those privileges on a particular table in that database or user space, the statement completes, but no rows are deleted from DBC.AccessRights because there are no rows correlating those privileges with that table for the specified database or user. Instead, the rows in DBC.AccessRights correlate the privileges with the containing user or database.
Consider the following space hierarchy: payroll human_resources pay_db table_a table_b table_c hr_db
1101A092
Suppose user payroll logs onto the system and grants the SELECT privilege on pay_db to user
human_resources and all its descendents.
The BTEQ LOGON command and GRANT request look like this:
.LOGON tdpid/payroll,password
GRANT SELECT
ON pay_db
TO ALL human_resources;
Grant accepted.
User payroll later decides to revoke the SELECT privilege on table_c in database pay_db from
human_resources and its descendents. To revoke this privilege, user payroll submits the following REVOKE request:
REVOKE SELECT
ON table_c
FROM ALL human_resources;
Revoke accepted.
Payroll now believes that the SELECT privilege on table_c has been revoked for
human_resources and its descendents, but it has not been revoked because there were never any rows in DBC.AccessRights granting that privilege to human_resources on table_c. The row granting the SELECT privilege on the entire pay_db database to human_resources remains in
DBC.AccessRights, so the originally granted SELECT privilege remains in effect.
SQL Data Control Language 117
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Rules for Revoking SQL Privileges
The following rules apply to various aspects of the SQL REVOKE statement:
•
Implicit privileges are governed by ownership and cannot be revoked. You can affect implicit privileges by using the GIVE statement to change ownership (see
for more information).
•
Any combination of privileges can be revoked by a user who has those privileges, either implicitly or explicitly, WITH GRANT OPTION.
•
The system does not automatically revoke privileges previously granted by a user after that user is dropped from the system.
•
Revoked privileges do not cascade through the hierarchy unless you specify the ALL
user_name option.
Conversely, if a privilege that was granted to ALL users and databases is revoked from
user_name, the privilege is not granted automatically to future users and databases that are owned by user_name.
•
If the object is a view, stored procedure, or macro, the requesting user also must have
WITH GRANT OPTION and all other applicable privileges on the objects referenced by that view, stored procedure, or macro.
•
If a REVOKE statement removes explicit privileges that were granted at the database- or user-level, the privileges are revoked for all objects, regardless of when they were created.
A REVOKE statement at the object level cannot remove a privilege from that object that was granted at the database- or user-level (see
“Privileges Must Be Revoked At The Same
Level As They Were Granted” on page 116 ).
•
If a user receives the same privilege from one or more grantors, any user who has the necessary privileges can revoke that privilege from the user and from other grantees. In other words, a person who revokes a privilege from another need not be the grantor of that privilege.
•
If a privilege was granted to PUBLIC, the privilege can only be revoked from PUBLIC, not from individual users.
•
Revocation of a column-level privilege is only allowed if there is a row in DBC.AccessRights for the columns on which the privilege is to be revoked. This means that if the user has
INSERT, REFERENCES, SELECT, or UPDATE privileges at the table level, revoking those privileges on individual columns is not allowed.
Revoking Privileges on Global Temporary and Volatile Tables
REVOKE always applies to the base global temporary table and never to a materialized instance. Just as with permanent tables, a user must have the appropriate prerequisite privileges before submitting a REVOKE statement.
Because no privilege checking is done for volatile tables, you cannot REVOKE any privileges on them.
118 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Revoking Privileges on Stored Procedures
The following rules apply to privileges specific to stored procedures:
•
CREATE PROCEDURE is only a database- or user-level privilege.
•
ALTER PROCEDURE, DROP PROCEDURE, and EXECUTE PROCEDURE apply to databases, users, or specified stored procedures.
•
DROP and EXECUTE can be used as abbreviations for DROP PROCEDURE and
EXECUTE PROCEDURE while rescinding privileges if you specify PROCEDURE
procedure_name.
•
The following happens if PROCEDURE is not specified before object_name:
IF the request is …
REVOKE EXECUTE
REVOKE DROP
THEN …
the object is assumed to be a macro.
If no macro by that name exists, an error or failure is returned.
an error/failure is returned.
Revoking UDT-Related Privileges
See the following topics for information about UDT-related privileges:
•
“UDT-Related Privileges” on page 70
•
“ALL PRIVILEGES and UDTs” on page 71
•
“UDTUSAGE Privilege” on page 72
•
“UDTTYPE Privilege” on page 73
•
“UDTMETHOD Privilege” on page 73
See
“Example 7: Revoking UDT-Related Privileges” on page 123 for examples of revoking
UDT-related privileges.
Revoking Privileges From Roles
Revoking a privilege from a role does not necessarily revoke the privilege from all of its role members. A member who has been granted the same privilege on an individual basis or through another role retains that privilege until it is explicitly revoked.
Revoking the CTCONTROL Privilege
If you specify the GRANT OPTION FOR option with a REVOKE request on the
CTCONTROL privilege, the specification removes only the ability of the recipient to grant the privilege to others. The CTCONTROL privilege itself is not revoked when you specify GRANT
OPTION FOR. Instead, you must submit a REVOKE request on the user that does not specify
GRANT OPTION FOR.
SQL Data Control Language 119
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
GRANT/REVOKE Order and Duration of Privileges
If a GRANT ALL ON object TO PUBLIC statement is issued by any user on an object that is lower in the hierarchy than user DBC, all other users inherit privileges on that object, including users created after the GRANT request is issued.
If user DBC then issues a REVOKE ALL ON object_name FROM DBC, users created after the
REVOKE request was issued are not granted privileges on that object. However, all previously created users retain the privileges until a REVOKE ALL ON object_name FROM PUBLIC is issued.
For example:
.LOGON dbc.password
CREATE USER sys_admin AS
PERM=900000 PASSWORD=sys_admin;
GRANT ALL
ON sys_admin
TO sys_admin
WITH GRANT OPTION;
.LOGON sys_admin,sys_admin
CREATE USER dept AS
PERM=500000 PASSWORD=dept;
GRANT ALL
ON dept
TO dept
WITH GRANT OPTION;
.LOGON DEPT,DEPT
CREATE USER user_1 AS
PERM=100000 PASSWORD=user_1;
.LOGON USER1,USER1
CREATE TABLE table_1 ( column_1 INTEGER, column_2 INTEGER)
PRIMARY INDEX(column_1);
INSERT table_1(1,2);
INSERT table_1(3,4);
GRANT ALL ON table_1
TO ALL DBC;
.LOGON dept,dept
CREATE USER user_2 AS
PERM=100000 PASSWORD=user_2;
.LOGON user_2,user_2
120 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
SELECT *
FROM user_1.table_1;
The rows of table_1 are returned as expected.
.LOGON dbc,password
REVOKE ALL ON user_1.table_1
FROM dbc;
.LOGON dept,dept
CREATE USER user_3 AS
PERM=100000 PASSWORD=user_3;
.LOGON user_3,user_3
SELECT *
FROM user_1.table_1;
An error is returned because user_3 was created after the REVOKE was issued.
.LOGON user_2,user_2
SELECT *
FROM user_1.table_1;
The contents of table_1 are returned as expected.
Example 1
This request revokes the INSERT privilege from UserA on the employee table:
REVOKE INSERT
ON personnel.employee
FROM UserA;
Example 2
This request revokes from UserA any access to any object that requires database, but not table, privileges in the personnel database:
REVOKE ALL PRIVILEGES
ON personnel
FROM UserA;
Example 3
This request leaves UserA with table privileges and at least the SELECT privilege on the
Department table:
REVOKE ALL BUT SELECT
ON Personnel.Department
FROM UserA;
The statement does not revoke database-level privileges or table-level privileges that UserA might have had on personnel; therefore, UserA might still have the ability to perform other requests such as an INSERT into personnel.department.
SQL Data Control Language 121
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
Example 4
This request leaves UserA with the SELECT privilege and all table-level privileges on every object in the personnel database:
REVOKE ALL BUT SELECT
ON personnel
FROM UserA;
Example 5: Stored Procedures
The EXECUTE PROCEDURE privilege of user_2 on the stored procedure named
stored_procedure_name in database_name must be revoked. Assume that all the specified database objects exist and that the grantor owns both the database and the stored procedure.
You can submit any of the following REVOKE statements to revoke the specified privileges:
REVOKE EXECUTE
ON PROCEDURE database_name.stored_procedure_name
FROM user_2;
REVOKE EXECUTE PROCEDURE
ON database_name.stored_procedure_name
FROM user_2;
REVOKE EXECUTE PROCEDURE
ON PROCEDURE database_name.stored_procedure_name
FROM user_2;
Submit the following statement to revoke CREATE PROCEDURE, DROP PROCEDURE, and
EXECUTE PROCEDURE privileges simultaneously from user_2 on the database named
database_name:
REVOKE CREATE PROCEDURE, DROP PROCEDURE, EXECUTE PROCEDURE
ON database_name
FROM user_2;
To revoke ALTER PROCEDURE, EXECUTE, and DROP privileges simultaneously from
user_2 on the stored procedure named stored_procedure_name in database database_name, you can perform either of the following requests:
REVOKE ALTER PROCEDURE, EXECUTE, DROP
ON PROCEDURE database_name.stored_procedure_name
FROM user2;
REVOKE ALL
ON PROCEDURE database_name.stored_procedure_name
FROM user2;
If you specify PROCEDURE without also specifying either CREATE or DROP in a REVOKE request, the system drops both the CREATE PROCEDURE and DROP PROCEDURE privileges on database_name.
122 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE (SQL Form)
For example, the following request drops both CREATE and DROP PROCEDURE privileges on database_name from user_2:
REVOKE PROCEDURE
ON database_name
FROM user_2;
Example 6
This request revokes the privilege from the Finance role to change the Personnel database:
REVOKE UPDATE, DELETE, INSERT
ON Personnel
FROM Finance;
Example 7: Revoking UDT-Related Privileges
The following examples provide a representative sample of how to revoke UDT-related privileges:
REVOKE UDTUSAGE
ON SYSUDTLIB
FROM tester1;
REVOKE UDTMETHOD
ON SYSUDTLIB
FROM User_DBA;
REVOKE UDTMETHOD
ON SYSUDTLIB
FROM Developer_Role;
Example 8: Revoking the CTCONTROL Privilege
The following example revokes from user kate the privilege to grant the CONNECT
THROUGH privilege to any user defined to Teradata Database:
REVOKE CTCONTROL FROM kate;
Note that this request revokes the CTCONTROL privilege from kate, not just her ability to grant CTCONTROL to other users, which would be the outcome of the following similar appearing request:
REVOKE GRANT OPTION FOR CTCONTROL FROM kate;
See
“Revoking the CTCONTROL Privilege” on page 119
for further information about this important distinction.
Related Topics
See
“GRANT (SQL Form)” on page 41 for information about granting SQL privileges.
SQL Data Control Language 123
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE CONNECT THROUGH
REVOKE CONNECT THROUGH
Purpose
Syntax
Revokes an existing proxy CONNECT THROUGH privilege from a permanent user or application user.
REVOKE CONNECT THROUGH trusted_user_name TO
FROM
,
25 application_user_name
,
PERMANENT
25 permanent_user_name
A where:
WITH ROLE
,
15
role_name
;
A
1101A542
Syntax element … Specifies …
trusted_user_name
the name of the trusted user whose CONNECT THROUGH privilege is being revoked.
application_user_name
the name of an application user from whom the proxy logon privileges granted through trusted_user_name are being revoked.
If you do not specify a WITH ROLE clause, the request revokes the connect privilege for the specified application user.
You can specify a maximum of 25 names in a single revoke request.
permanent_user_name
the name of a permanent user from whom the proxy logon privileges granted through trusted_user_name are being revoked.
If you do not specify a WITH ROLE clause, the request revokes the connect privilege for each permanent user from the trusted user.
You can specify a maximum of 25 names in a single revoke request.
124 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE CONNECT THROUGH
Syntax element …
role_name
Specifies …
a list of role names to be removed from the CONNECT THROUGH privilege granted to trusted_user_name.
If you specify to remove all roles that have been granted the CONNECT
THROUGH privilege for the specified permanent or application user, then the system revokes the entire privilege for the specified permanent or application user.
Similarly, if you do not specify a WITH ROLE clause, then the system revokes the entire privilege for the specified permanent or application user.
If the user whose privileges are being revoked is an application proxy user and this is the last remaining role for the grant privilege, the system also revokes the connect privilege for the proxy user.
ANSI Compliance
REVOKE CONNECT is a Teradata extension to the ANSI SQL:2008 standard.
Required Privileges
You must have the CTCONTROL privilege (see “CTCONTROL Privilege” on page 65
) to perform a REVOKE CONNECT request.
If the request specifies a WITH ROLE clause, you must also have the WITH ADMIN OPTION privilege on each of the roles specified in the clause.
Role Persistence Through Active Proxy Connections
Changes to a CONNECT THROUGH privilege definition are effective immediately, so the next request submitted in a proxy connection following a change to a CONNECT THROUGH privilege uses the new definition.
When roles are dropped, they are also removed from the CONNECT THROUGH privilege definition, so it is possible for a rule to be left with no roles defined for it. When you drop all of the roles that were assigned to a CONNECT THROUGH privilege definition, Teradata
Database grants the affected proxy users PUBLIC privileges only.
CONNECT THROUGH and Parameter Markers
Parameter markers are not supported for REVOKE CONNECT requests.
SQL Data Control Language 125
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE CONNECT THROUGH
Dictionary Storage of CONNECT THROUGH Metadata
The dictionary table DBC.ConnectRulesTbl stores information on which proxy users can connect through which trusted users and what roles are available to make proxy connections.
DBC.ConnectRulesTbl contains one row for every trusted_user_name:proxy_user_name combination that has been defined.
To provide an audit trail for the management of the rules, the system retains the row in
DBC.ConnectRulesTbl when a privilege is revoked.
The DBC.ConnectRulesTbl.GrantStatus column for each privilege contains a G if the privilege is granted and an R if it is revoked.
See
“Dictionary Storage of CONNECT THROUGH Metadata” on page 90
and Data
Dictionary for details about DBC.ConnectRulesTbl.
Example
The following REVOKE CONNECT request revokes the CONNECT THROUGH privilege that had been granted to permanent user sbd with the role admin through trusted user pls.
REVOKE CONNECT THROUGH pls FROM PERMANENT sbd WITH ROLE admin;
Related Topics
FOR more information on …
Granting proxy connections
Setting query bands to enable proxy connections
Administering trusted sessions
Security issues related to trusted sessions
The dictionary attributes of trusted sessions
SEE …
“GRANT CONNECT THROUGH” on page 83
“SET QUERY_BAND” in SQL Data Definition
Language
Database Administration
Security Administration
Data Dictionary
126 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE LOGON
REVOKE LOGON
Purpose
Syntax
Does either of the following.
•
Revokes permission to log onto Teradata Database from one or more specific client systems.
•
Changes the current system logon defaults.
REVOKE LOGON ON
,
host_id
ALL
AS DEFAULT
TO
,
user_name
FROM
;
1101B036 where:
Syntax Element...
Specifies...
host_id an integer that identifies a mainframe channel connection or a LAN connection that is currently defined to the system by the hardware configuration data. The interface need not be operational.
The value for the Teradata Database console is 0.
For any other connector, the value for host_id ranges from 1 to 1023, inclusive.
ALL
AS DEFAULT
FOR this platform operating system
…
UNIX
Windows
You can define this many host_ids per node …
1.
multiple.
any source through which a logon is attempted, including the Teradata Database console.
that the current default for the specified host ID set is to be changed, without residual conditions, as defined in this REVOKE LOGON statement.
A statement with AS DEFAULT has no effect on the access revoked from or granted to particular user names. A statement that sets the default for a specific host ID takes precedence over a statement that sets the default for ALL client systems.
SQL Data Control Language 127
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE LOGON
Syntax Element...
Specifies...
TO
FROM
user_name
keywords introduced to override the current default for the specified
database_name_list or user_name set on the specified host_ID set.
a user name in a list of users from which logons are to be revoked.
The name DBC cannot be specified as a user_name in a REVOKE LOGON statement. Any such statement that includes the name DBC returns an error message.
The product of the number of host IDs and the number of database and user names cannot exceed 25.
ANSI Compliance
REVOKE LOGON is an extension to the ANSI SQL:2008 standard.
Required Privileges
You must have the EXECUTE privilege on the DBC.LogonRule macro to perform REVOKE
LOGON.
No checks are made on whether the database names or user names defined in the statement apply to users owned by the requesting user.
If the system cannot verify the submitted statement because it specifies a nonvalid user name or a nonvalid host ID, then it aborts returns an error.
Default Logon Permissions
When Teradata Database is connected to multiple client systems, the initial default is that logon permission is granted to all users from all host IDs, and that all logons must include a password.
•
The GRANT LOGON and REVOKE LOGON statements control which users have access from which client system connections.
•
A REVOKE LOGON statement inhibits only future logon attempts; it does not affect users who are currently logged on.
128 SQL Data Control Language
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE LOGON
Each REVOKE LOGON Statement Creates A New Control Record
When you enter a REVOKE LOGON statement for one or more user names, a logon control record is created for each user name-host ID pair specified.
Any existing control record for a particular pair is replaced. The logon control record set created for a particular user name exists until that user is dropped (see “DROP USER” in SQL
Data Definition Language).
REVOKE LOGON on User DBC Is Not Valid
Any attempt to REVOKE LOGON for user name DBC returns an error. If an attempt is made to log onto the system with user name DBC and the correct password is submitted, then the logon is accepted regardless of the current default for the applicable host ID. This prevents any opportunity to lock out all hosts from user DBC.
AS DEFAULT Option
A request that includes the AS DEFAULT option has no effect on the logon access granted to or revoked from specific user names.
The following rules apply to the AS DEFAULT option:
A user named in this type of statement …
REVOKE LOGON
GRANT LOGON
Assumes these privileges …
cannot access the applicable client even if that client has an assigned default of GRANT.
can always access the applicable client even if that client has an assigned default of REVOKE.
Related Topics
See
“GRANT LOGON” on page 93 for information about granting logon privileges.
SQL Data Control Language 129
Chapter 2: SQL Data Control Language Statement Syntax
REVOKE LOGON
130 SQL Data Control Language
APPENDIX A
Notation Conventions
This appendix describes the notation conventions used in this book.
Throughout this book, three conventions are used to describe the SQL syntax and code:
•
Syntax diagrams, used to describe SQL syntax form, including options.
•
Square braces in the text, used to represent options. The indicated parentheses are required when you specify options.
For example:
•
DECIMAL [(n[,m])] means the decimal data type can be defined optionally:
•
without specifying the precision value n or scale value m
•
specifying precision (n) only
•
specifying both values (n,m)
•
you cannot specify scale without first defining precision
•
CHARACTER [(n)] means that use of (n) is optional.
The values for n and m are integers in all cases.
•
Japanese character code shorthand notation, used to represent unprintable Japanese
characters. See “Character Shorthand Notation Used In This Book” on page 137
.
Symbols from the predicate calculus are also used occasionally to describe logical operations.
SQL Data Control Language 131
Appendix A: Notation Conventions
Syntax Diagram Conventions
Syntax Diagram Conventions
Notation Conventions
Item
Letter
Number
Word
Spaces
Punctuation
Definition / Comments
An uppercase or lowercase alphabetic character ranging from A through Z.
A digit ranging from 0 through 9.
Do not use commas when typing a number with more than 3 digits.
Keywords and variables.
•
UPPERCASE LETTERS represent a keyword.
Syntax diagrams show all keywords in uppercase, unless operating system restrictions require them to be in lowercase.
•
lowercase letters represent a keyword that you must type in lowercase, such as a
UNIX command.
•
lowercase italic letters represent a variable such as a column or table name.
Substitute the variable with a proper value.
•
lowercase bold letters represent an excerpt from the diagram. The excerpt is defined immediately following the diagram that contains it.
•
UNDERLINED LETTERS represent the default value.
This applies to both uppercase and lowercase words.
Use one space between items such as keywords or variables.
Type all punctuation exactly as it appears in the diagram.
Paths
The main path along the syntax diagram begins at the left with a keyword, and proceeds, left to right, to the vertical bar, which marks the end of the diagram. Paths that do not have an arrow or a vertical bar only show portions of the syntax.
The only part of a path that reads from right to left is a loop.
Continuation Links
Paths that are too long for one line use continuation links. Continuation links are circled letters indicating the beginning and end of a link:
A
A
FE0CA002
132 SQL Data Control Language
Appendix A: Notation Conventions
Syntax Diagram Conventions
When you see a circled letter in a syntax diagram, go to the corresponding circled letter and continue reading.
Required Entries
Required entries appear on the main path:
SHOW
FE0CA003
If you can choose from more than one entry, the choices appear vertically, in a stack. The first entry appears on the main path:
SHOW
CONTROLS
VERSIONS
FE0CA005
Optional Entries
You may choose to include or disregard optional entries. Optional entries appear below the main path:
SHOW
CONTROLS
FE0CA004
If you can optionally choose from more than one entry, all the choices appear below the main path:
READ
SHARE
ACCESS
JC01A010
Some commands and statements treat one of the optional choices as a default value. This value is UNDERLINED. It is presumed to be selected if you type the command or statement without specifying one of the options.
SQL Data Control Language 133
Appendix A: Notation Conventions
Syntax Diagram Conventions
Strings
String literals appear in single quotes:
' msgtext
'
JC01A004
Abbreviations
If a keyword or a reserved word has a valid abbreviation, the unabbreviated form always appears on the main path. The shortest valid abbreviation appears beneath.
Loops
SHOW
CONTROLS
CONTROL
In the above syntax, the following formats are valid:
•
SHOW CONTROLS
•
SHOW CONTROL
FE0CA042
A loop is an entry or a group of entries that you can repeat one or more times. Syntax diagrams show loops as a return path above the main path, over the item or items that you can repeat:
(
,
,
cname
4
3
)
JC01B012
Read loops from right to left.
The following conventions apply to loops:
IF...
there is a maximum number of entries allowed there is a minimum number of entries required
THEN...
the number appears in a circle on the return path.
In the example, you may type cname a maximum of 4 times.
the number appears in a square on the return path.
In the example, you must type at least three groups of column names.
134 SQL Data Control Language
Appendix A: Notation Conventions
Syntax Diagram Conventions
IF...
a separator character is required between entries a delimiter character is required around entries
THEN...
the character appears on the return path.
If the diagram does not show a separator character, use one blank space.
In the example, the separator character is a comma.
the beginning and end characters appear outside the return path.
Generally, a space is not needed between delimiter characters and entries.
In the example, the delimiter characters are the left and right parentheses.
Excerpts
Sometimes a piece of a syntax phrase is too large to fit into the diagram. Such a phrase is indicated by a break in the path, marked by (|) terminators on each side of the break. The name for the excerpted piece appears between the terminators in boldface type.
The boldface excerpt name and the excerpted phrase appears immediately after the main diagram. The excerpted phrase starts and ends with a plain horizontal line:
LOCKING
A
HAVING
con
excerpt
A
excerpt
where_cond
,
cname
,
col_pos
JC01A014
Multiple Legitimate Phrases
In a syntax diagram, it is possible for any number of phrases to be legitimate:
DATABASE
TABLE
VIEW dbname tname vname
In this example, any of the following phrases are legitimate:
SQL Data Control Language
JC01A016
135
Appendix A: Notation Conventions
Syntax Diagram Conventions
•
dbname
•
DATABASE dbname
•
tname
•
TABLE tname
•
vname
•
VIEW vname
Sample Syntax Diagram
CREATE VIEW
CV viewname
,
cname
A
B dbname
DATABASE tname
TABLE
SEL
VIEW
,
expr vname
FROM
FOR
IN
,
tname
AS
LOCKING
LOCK
ACCESS
SHARE
READ
WRITE
EXCLUSIVE
EXCL
MODE
qual_cond
.aname
C
HAVING cond
; qual_cond
WHERE cond
GROUP BY
,
cname
,
col_pos
A
B
C
JC01A018
Diagram Identifier
The alphanumeric string that appears in the lower right corner of every diagram is an internal identifier used to catalog the diagram. The text never refers to this string.
136 SQL Data Control Language
Appendix A: Notation Conventions
Character Shorthand Notation Used In This Book
Character Shorthand Notation Used In This
Book
Introduction
This book uses the Unicode naming convention for characters. For example, the lowercase character ‘a’ is more formally specified as either LATIN SMALL LETTER A or U+0041. The
U+xxxx notation refers to a particular code point in the Unicode standard, where xxxx stands for the hexadecimal representation of the 16-bit value defined in the standard.
In parts of the book, it is convenient to use a symbol to represent a special character, or a particular class of characters. This is particularly true in discussion of the following Japanese character encodings.
•
KanjiEBCDIC
•
KanjiEUC
•
KanjiShift-JIS
These encodings are further defined in International Character Set Support.
Character Symbols
The symbols, along with character sets with which they are used, are defined in the following table.
Symbol
a–z
A–Z
0–9 a–z
A–Z
0–9
<
>
T
Encoding
Any
Meaning
Any single byte Latin letter or digit.
Unicode compatibility zone
Any fullwidth Latin letter or digit.
KanjiEBCDIC Shift Out [SO] (0x0E).
Indicates transition from single to multibyte character in
KanjiEBCDIC.
KanjiEBCDIC Shift In [SI] (0x0F).
Indicates transition from multibyte to single byte KanjiEBCDIC.
Any Any multibyte character.
The encoding depends on the current character set.
For KanjiEUC, code set 3 characters are sometimes preceded by
“ss
3
”.
SQL Data Control Language 137
Appendix A: Notation Conventions
Character Shorthand Notation Used In This Book
∆
∆
Symbol
I
Encoding
Any
Any
Any
Meaning
Any single byte Hankaku Katakana character.
In KanjiEUC, it must be preceded by “ss
2
”, forming an individual multibyte character.
Represents the graphic pad character.
Represents a single or multibyte pad character, depending on context.
Represents the EUC code set 2 introducer (0x8E).
Represents the EUC code set 3 introducer (0x8F).
ss
2 ss
3
KanjiEUC
KanjiEUC
For example, string “TEST”, where each letter is intended to be a fullwidth character, is written as TEST. Occasionally, when encoding is important, hexadecimal representation is used.
For example, the following mixed single byte/multibyte character data in KanjiEBCDIC character set
LMN<TEST>QRS is represented as:
D3 D4 D5 0E 42E3 42C5 42E2 42E3 0F D8 D9 E2
Pad Characters
The following table lists the pad characters for the various character data types.
Server Character Set
LATIN
UNICODE
GRAPHIC
KANJISJIS
KANJI1
Pad Character Name
SPACE
SPACE
IDEOGRAPHIC SPACE
ASCII SPACE
ASCII SPACE
0x20
Pad Character Value
U+0020
U+3000
0x20
0x20
138 SQL Data Control Language
Glossary
ACM
Association for Computing Machinery
AMP
Access Module Processor vproc
The set of software services that controls the file system and data management components of a Teradata Database.
ANSI
American National Standards Institute ( http://www.ansi.org
)
A US-based umbrella standards organization based in Washington, D.C., that defines, certifies, and administers the SQL standard.
The ANSI SQL standards are available for purchase at the following web site: http:// webstore.ansi.org/ansidocstore/find.asp?
The ANSI SQL standard is also recognized by the
.
API
Application Programming Interface.
A set of software services with a well-defined program interface.
Application User
Application users are proxies for middle tier applications that access
Teradata Database by means of a session logged onto by a
.
An application proxy user can be anything that represents a client connecting to the middle tier such as a client name or an Automated Teller Machine ID.
Application proxy user names are not defined in Teradata Database, so the system does not valid their names, but the names must follow Teradata object naming conventions.
Along with the category of
Permanent User application users are more broadly referred to as a
ASCII
American Standard Code for Information Interchange
A standard seven-bit code designed to establish compatibility between various types of data processing equipment. Originally proposed in 1963, ASCII is documented by the following standards: ISO-14962-1997 and ANSI-X3.4-1986(R1997).
The standard ASCII character set defines 128 decimal numbers ranging from 0 through 127, inclusive. The individual characters are assigned to alphanumerics, punctuation marks, and a set of commonly used special characters.
There is also an extended ASCII character set consisting of an additional 128 decimal numbers ranging from 128 through 255, inclusive. These characters are assigned to additional special, mathematical, graphic, and “foreign” characters.
Because ASCII uses only 7 bits, it is possible to use the 8th bit for parity checking.
.
SQL Data Control Language 139
Glossary
140
BLOB
Binary Large OBject
A data object, usually larger than 64K, that contains only binary data such as pictures, movies, or music.
.
BNF
Backus-Naur Form or Backus Normal Form
A metalanguage used to specify computer languages.
BTEQ
Basic Teradata Query facility
A client interface to Teradata Database that permits users to submit SQL requests interactively or in batch mode, to format result sets, to build and perform scripts, and to import and export data.
BTEQ is based on the CLIv2 API, while the somewhat similar facility, SQL Assistant, is based on the ODBC API. As a result, there are several significant differences in the behavior of the two facilities.
BYNET
BanYan NETwork - A proprietary high speed hybrid hardware and software communications network that handles the data flow between the PEs and AMPs running on
nodes in a Teradata system.
C
A general-purpose programming language developed by Dennis Ritchie of AT&T Bell
Laboratories.
C++
An object-oriented programming language developed by Bjarne Stroustrup of AT&T
Bell Laboratories as an extension to the
language.
CLIv2
Call Level Interface Version 2
CLIv2 is the API for most client-server interactions in Teradata Database. The applications that do not use CLIv2, such as SQL Assistant, use the ODBC API to communicate between the client and the Teradata server.
CLOB
Character Large OBject
A data object, usually larger than 64K, that contains only character data such as XML or other text files.
Connection Pool
Connection pooling is a technique for sharing platform resources among various requesting clients. It allows multiple clients to share a cached set of connection objects that provides access to Teradata Database. Connection pooling improves performance by eliminating the overhead associated with establishing a new connection to Teradata Database for each request.
Also see
,
,
Proxy Connection , Proxy Role , Proxy User
, and
.
SQL Data Control Language
Glossary
EBCDIC
Extended Binary-Coded Decimal Interchange Code
An 8-bit code for alphanumerics, punctuation marks, and special characters devised by IBM
Corporation as an alternative to ASCII
EBCDIC and ASCII use different coding schemes to define their respective character sets, and EBCDIC defines some special characters that are not defined in ASCII. EBCDIC is only used by IBM computing equipment.
Because EBCDIC is an 8-bit coding scheme, it is not possible to perform parity checks using the 8th bit.
External Routine
A generic term to describe stored procedures, user-defined functions, and user-defined methods.
EXTUSER
External USER
FK
See
.
Foreign Key
Foreign Key
A means of establishing referential integrity between tables in a relational database. A foreign key in a child table is typically the logical primary key of its parent table. If it is not the primary key for the parent table, then it is one of its alternate keys.
GDO
Global Distributed Object.
Global Temporary Table
Global Temporary Table
A type of table whose definition persists across sessions, but whose contents typically do not.
You can materialize only one instance of a global temporary table within the same session, but up to 2 000 different global temporary table instances within the same session, and there is no limit to the number of sessions that can materialize an instance of the same global temporary table definition. Global temporary tables are also limited by not being indexable, not eligible to have statistics collected on their columns, not being compressible, not eligible for permanent journaling (though global temporary table updates can optionally be logged), not eligible to define most types of constraints, and so on. See “Global Temporary Tables” in SQL
Data Definition Language for a complete definition of global temporary tables and a listing of their restrictions.
GLOP
An initialism for GLObal and Persistent data.
GLOPs enable external routines to access global shared memory that contains data of your choosing. GLOPs make it possible to use this data to make configurable business decisions without the need to externalize the information by means of parameters or other methods of passing data to external routines.
A GLOP persists beyond a single invocation of an external routine, enabling it to be referenced by subsequent external routines either in either its original, or modified, form.
SQL Data Control Language 141
Glossary
142
GLOP Set
A GLOP set is the GLOP mapping that is accessed when it is referenced by a UDF, method, or external procedure.
A GLOP set consists of up to 8 GLOP data sections of various types.
GTT
Hash Index
Hash Index
A vertical partition of a base table having properties similar to a single-table
.
Unlike the primary index, which is stored in-line with the row it indexes, hash indexes are stored in separate subtables that must be maintained by the system. Hash index subtables also consume disk space, so you should monitor your queries periodically using EXPLAIN modifiers to determine whether the Optimizer is using any of the hash indexes you designed for them. If not, you should either drop those indexes or rewrite your queries in such a way that the Optimizer does use them.
HI
IEEE
Institute of Electrical and Electronics Engineers ( http://www.ieee.org
)
The leading US-based professional society for electrical and electronics engineers.
The largest of its member societies is the IEEE Computer Society ( http://www.computer.org
).
ISO
International Organization for Standardization http://www.iso.org
An international umbrella standards organization based in Geneva, Switzerland, that also certifies the ANSI SQL standard.
The following passage from the ISO web site explains why the name of the organization does not match its (apparent) initialism: “Because "International Organization for
Standardization" would have different abbreviations in different languages ("IOS" in English,
"OIN" in French for Organisation internationale de normalisation), it was decided at the outset to use a word derived from the Greek isos, meaning "equal". Therefore, whatever the country, whatever the language, the short form of the organization's name is always ISO.”
The ISO packaging of the SQL standard can be obtained from the following web site: http:// www.iso.org/iso/en/
StandardsQueryFormHandler.StandardsQueryFormHandler?scope=CATALOGUE&sortOrde r=ISO&committee=ALL&isoDocType=ALL&title=true&keyword=sql
Java
TM
A class-based, object-oriented programming language developed by Sun
Microsystems.
JI
Join Index
A vertical partition of one or more base tables that can, depending on how it is defined, create various types of prejoins of tables, including sparse and aggregate forms. Join indexes cannot be queried directly by an SQL request; instead, they are used by the Optimizer to enhance the performance of any queries they cover.
A join index that only vertically partitions a base table is referred to as a single-table join index.
SQL Data Control Language
Glossary
A join index that prejoins two or more base tables is referred to as a multitable join index.
Both types of join index can be created in sparse or aggregate forms and can have a subset of their columns compressed.
Unlike the primary index, which is stored in-line with the row it indexes, join indexes are stored in separate subtables that must be maintained by the system. Join index subtables also consume disk space, so you should monitor your queries periodically using EXPLAIN modifiers to determine whether the Optimizer is using any of the join indexes you designed for them. If not, you should either drop those indexes or rewrite your queries in such a way that the Optimizer does use them.
LOB
Large OBject
Any data object that is larger than the maximum row size for Teradata Database. There are two
types of LOB: the BLOB and the CLOB
.
NoPI Table
A table that has no primary index. All access to NoPI table rows is by means of a
full-table scan unless you define Secondary Index
es on the table.
See Database Design for details.
NPPI
NonPartitioned Primary Index
A
that is not partitioned into range buckets by means of a partitioning expression.
NUPI
Non-Unique Primary Index
A Primary Index that is not uniquely constrained. NUSIs are often used to position rows from
multiple tables on the same AMP to facilitate join operations on those tables.
NUSI
Non-Unique Secondary Index
An AMP-local
designed to be used for set (multirow) selection rather than single-row selection.
ODBC
Open DataBase Connectivity
A de facto standard API for communicating between client applications and relational databases using SQL.
The ANSI SQL standard API, referred to as CLI (sometimes as SQL/CLI), or Call-Level
Interface, is based on the ODBC specification. Beginning with ODBC version 3.0, the ODBC standard and the ANSI SQL Call Level Interface standards became identical.
See http://www.sqlsummit.com/ODBCPORT.HTM
.
OLTP
On-Line Transaction Processing
A category of workload processing that typically deals with very brief update transactions.
A typical application of OLTP technology is automated teller machines.
SQL Data Control Language 143
Glossary
144
OS
Operating System
A level of software that provides services to permit higher level software to interact with system hardware.
UNIX, Linux, Windows, and z/OS are examples of operating systems.
PDE
Parallel Database Extensions
A virtual machine layer between the Teradata Database software and the Teradata file system and the underlying operating system.
The PDE presents a common interface to the Teradata Database software that permits the
RDBMS and file system to be more easily ported to different operating systems.
PE
Parsing Engine vproc
The set of software services that controls the query processing and session management components of a Teradata Database.
Permanent User
Permanent users are proxies for users who access Teradata Database by
means of a session logged onto by a Trusted User
. In contrast to an
users are always defined within Teradata Database.
The privileges for a permanent proxy user are either those that have been defined for that permanent user or those defined by the roles assigned to the proxy user in the GRANT
CONNECT privileges for the
Trusted User under whose session the permanent user is logged
onto Teradata Database.
Along with the category of
Application User , application users are more broadly referred to as
PI
PK
PPI
Partitioned Primary Index
A Primary Index that is used to first distribute rows to the AMPs as they would be by an
then partitioned into a set of ranges determined by the DBA and specified using a
PARTITION BY clause in the table definition statement.
PPIs are particularly useful for supporting various types of range queries.
Primary Index
A set of columns in a table whose values are hashed to create a code used to distribute its rows to, and retrieve them from, the AMPs.
Each table in a Teradata database must have either none or one primary index, which might or might not be unique.
SQL Data Control Language
Glossary
Primary Key
A set of columns in a table whose values make each row in that table unique.
Primary keys are a logical, not physical, concept that are often, but not necessarily, used as the primary index for a table when it is physically designed.
A table can have multiple candidate keys, but only one primary key can be defined for it.
Those candidate keys that are not used as the primary key for a table are referred to as alternate keys.
Relationships between primary and foreign keys are often used to establish referential integrity between tables. These relationships are also frequently exploited by the Optimizer to enhance query performance.
Proxy Connection
A connection in which the user being validated for privileges and
Proxy Role
A role defined for a
.
If a proxy connection specifies a PROXYROLE=role_name string, role_name must be one of the role names specified in the WITH ROLE clause of the GRANT CONNECT THROUGH request that.
PROXYROLE is a reserved query band name used to enable asserting a proxy role by means of a SET QUERY_BAND request.
Proxy User
A user that connects to Teradata Database using the session of a
.
Application users and permanent users are collectively referred to as proxy users.
PROXYUSER is a reserved query band name used to enable asserting a proxy user by means of a SET QUERY_BAND request.
RDBMS
Relational DataBase Management System
A database management system based on relational set theory and the theorems, axioms, and operators provided by set theory. The set theoretic foundation for an RDBMS provides a scientific, predictable, set of tools for managing data.
Referential Integrity
A method of ensuring that no data is ever orphaned in a relational
database. Referential integrity uses the parent-child relationships between a Primary Key and
to prevent child table rows from ever being orphaned from deleted parent table rows.
The Teradata relational database management software supports three different kinds of relational integrity constraints:
•
Referential Integrity constraints
This is the standard RI constraint defined by the ANSI SQL standard.
•
Batch Referential Integrity constraints
This is a special Teradata Database form of RI that is less expensive to enforce in terms of system resources than standard referential integrity because it is enforced as an all-or-nothing operation (the entire transaction must complete successfully) rather than on a row-by-row basis, as standard referential integrity is checked.
SQL Data Control Language 145
Glossary
146
•
Referential Constraints
This is a special Teradata Database form of RI, sometimes informally referred to as soft RI, that specifies constraints the Optimizer can use to optimize queries, but are not enforced by the system. In other words, their referential constraint is logical only and is not enforced physically.
Referential integrity relationships are often used by the Optimizer to enhance query performance.
Request
One or more SQL statements submitted to Teradata Database as a single unit of work.
RI
See
Secondary Index
A vertically partitioned subset of base table columns used to facilitate data manipulation operations.
Unlike the primary index, which is stored in-line with the row it indexes, secondary indexes are stored in separate subtables that must be maintained by the system. Secondary index subtables also consume disk space, so you should monitor your queries periodically using
EXPLAIN modifiers to determine whether the Optimizer is using any of the secondary indexes you designed for them. If not, you should either drop those indexes or rewrite your queries in such a way that the Optimizer does use them.
Secondary indexes come in two types: USI
and
.
SI
See
SMP
Symmetric MultiProcessor. In the Teradata system architecture, an SMP is represented by a single node.
SQL
The programming language used to create relational database objects (Data Definition
Language, or DDL), to manipulate their contents (Data Manipulation Language, or DML), and to define their security attributes (Data Control Language, or DCL).
Now preferably pronounced ess-kew-ell, the language was originally named SEQUEL
(Structured English QUEry Language) and was pronounced as it was spelled. According to the
ANSI SQL standard, SQL does not stand for Structured Query Language, as is commonly thought. The name is neither an acronym nor does it represent anything other than the characters S, Q, and L.
Trusted User
A user who has been granted the privilege to assume the identity of a
UDT
User-Defined Type
A data type defined by someone other than Teradata. UDTs come in two variations: Distinct and Structured. See “CREATE TYPE (Distinct Form)” in SQL Data Definition Language,
“CREATE TYPE (Structured Form)” in SQL Data Definition Language, and SQL External
Routine Programming for additional information.
SQL Data Control Language
Glossary
UPI
Unique Primary Index
A
that is uniquely constrained. The rows from a table defined with a UPI tend to be distributed more evenly across the AMPs than rows from a table defined with a
USI
Unique Secondary Index
A
Secondary Index designed to facilitate single-row access.
Volatile Table
Volatile Table
A type of table that is private to the session in which it is created and persists only for the duration of that session. Volatile tables are also limited by not being indexable, not eligible to have statistics collected on their columns, not being compressible, not eligible for journaling, not eligible to define most types of constraints, and so on. See SQL Data Definition Language for a complete definition of volatile tables and a listing of their restrictions.
Compare with Global Temporary Table
vproc
Virtual Process
The Version 1 Teradata architecture used several different specialized node types to process data, including the following node types:
•
IFP (InterFace Processor)
•
COP (Communications Processor)
•
APP (Application Processor)
•
The Version 2 Teradata architecture is based on a common node configuration. Each TPA
and
vprocs that emulate the functions of the Version 1 hardware nodes. The functions IFP and COP nodes of the Version 1 architecture are consolidated in the PE vproc, while the analogous functionality of an APP node of the Version
1 architecture is running Teradata Tools and Utilities software on a non-TPA node in a
Teradata MPP system.
VT
See
.
XSP
EXternal Stored Procedure
A stored procedure whose procedural code is contained in an external routine that is written in a language other than SQL such as C, C++, or Java.
Compare with SQL stored procedure, in which the procedural code is contained in a routine internal to Teradata Database and written in the SQL language.
SQL Data Control Language 147
Glossary
148 SQL Data Control Language
Index
A
ABORTSESSION monitor privilege 34
Application proxy user 84, 86, 88, 124
C
Column-level privileges
granting column-level privileges 56
CONNECT THROUGH privilege 83, 124
CREATE EXTERNAL PROCEDURE privilege 68
Creator
privileges 16 rules for creators 16
D
Database
compared with user 12 definition 12
E
Explicit privileges 22, 24 automatic granting of explicit privileges 22
characteristics of explicit privileges 23
reporting contents of DBC.AccessRights table 23
summarized in contrast with implicit privileges 24
External authentication
G
Global temporary tables
rules for revoking privileges on 118
GRANT (Monitor Form) statement 34
GRANT (MONITOR Form) statement contrasted with
GRANT (Role Form) 38 granting role membership 38
GRANT (SQL Form) and GRANT (MONITOR Form) statements 36
GRANT (SQL Form) statement contrasted with GRANT
GRANT CONNECT THROUGH statement 83
Granting column-level privileges 56
Granting privileges to others 18
I
Immediate owner
summarized in contrast with explicit privileges 24
J
Japanese character code notation
SQL Data Control Language 149
Index
L
Logging on
using external authentication 96
Logon
M
MONRESOURCES monitor privilege 34
MONSESSION monitor privilege 35
O
Objects
Owner
privileges 16 rules for owners 16
P
Password
requirements for the GRANT LOGON statement 95
Permanent proxy user 84, 86, 88, 124
CREATE EXTERNAL PROCEDURE privilege 68
creation principles summarized 16
data dictionary abbreviations for privileges 53, 114
establishing privileges using GRANT 33
granting privileges to others 18
MONITOR-related privileges for GRANT (Monitor
MONRESOURCES monitor privilege 34
MONSESSION monitor privilege 35
ownership principles summarized 16
privileges on stored procedures 66
restrictions on granted privileges 58
SETRESRATES monitor privilege 35
SETSESSRATE monitor privilege 35
when privileges become effective 55
where privileges are stored 11
Proxy users
application proxy user 84, 86, 88, 124
permanent proxy user 84, 86, 88, 124
150 SQL Data Control Language
R
REVOKE (Monitor Form) statement 100
revokable privileges 102 rules for use 102
REVOKE (Role Form) statement 104 revoking role membership 104
REVOKE (SQL Form) and REVOKE (MONITOR Form) statements 102
REVOKE (SQL Form) statement 107
rules for revoking privileges 118
REVOKE CONNECT THROUGH statement 124
cannot revoke logon for user DBC 129
Roles
rules for revoking privileges from 119
Rules
REVOKE (SQL Form) statement 115
Rules for revoking privileges
REVOKE (SQL Form) 118 volatile tables 118
Rules for revoking privileges from roles 119
Rules for revoking privileges from UDTs 119
Rules for revoking privileges on stored procedures 119
S
SETRESRATE monitor privilege 35
SETSESSRATE monitor privilege 35
SQL statements
GRANT (Role Form) statement 38
GRANT CONNECT THROUGH statement 83
Syntax diagrams
T
Trusted sessions
application proxy user 84, 86, 88, 124
GRANT CONNECT THROUGH statement 83
permanent proxy user 84, 86, 88, 124
REVOKE CONNECT THROUGH statement 124
trusted user 83, 84, 86, 89, 124
Trusted user 83, 84, 86, 89, 124
U
Unicode character naming convention 137
User
compared with database 12 definition 12
V
Volatile tables
rules for revoking privileges on 118
Index
SQL Data Control Language 151
Index
152 SQL Data Control Language
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
Key features
SQL Data Control Language (DCL)
Privilege management
User and role-based access control
GRANT and REVOKE statements
Data security
Performance monitoring privileges
Frequently asked questions
The GIVE statement transfers ownership of an object from one user or database to another.
The GRANT statement assigns privileges to specified users, databases, and roles.
The REVOKE statement rescinds privileges from specified users, databases, and roles.
