Does REVOKE always block an operation completely?

No. Another valid authorization path may remain.

Are GRANT and REVOKE identical across all database products?

No. Syntax and detailed behavior require system-specific documentation.

Does permission to read imply permission to update?

No. These are distinct operations in typical privilege models.

AI Glossary / Data engineering and architecture / Advanced

Data control language

Definition

Data control language, usually abbreviated DCL, is a common category name for database commands that manage permissions. Typical examples are GRANT, which assigns specified privileges, and REVOKE, which removes specified grants. The label describes access-control operations within a database language. Exact syntax, command classification and permission behavior vary among database systems, so the category should not be treated as a universal implementation specification.

What it means

A database user may be allowed to read a table without being allowed to change it. Another role may manage selected records or execute a particular stored routine. DCL commands help express those permissions. They do not themselves define the business meaning of the data or guarantee that an application uses it correctly. A permission change also needs to be interpreted within the complete access model, including roles, ownership and any other routes through which the same capability is available.

How it works

An authorized administrator or other permitted grantor identifies a privilege, its target object and the receiving user or role. A grant adds the specified authorization, while a revoke removes a specified grant or grant option under the system's rules. PostgreSQL documents that access can remain through another privilege path after one grant is revoked. Therefore, the effective result must be checked rather than inferred from one command in isolation. Database-specific documentation determines details such as dependencies, role behavior and which actor has authority to make the change.

Three practical examples

A reporting role receives permission to read a defined table without receiving permission to update it.
An administrator removes a temporary grant after a limited maintenance task has ended.
A team investigates why an account still reads an object after one direct grant is removed and finds another valid permission path.

Think of it this way

Imagine a building where a person has both an individual access card and membership in a group with entry rights. Canceling one route may leave the other available. Database permissions can have a similar structure, although the exact rules differ by system. The analogy highlights why the important question is whether access remains possible, rather than merely whether one administrative action succeeded. It does not imply that every database implements explicit denials or group precedence in the same way.

Worked example

Consider an original simplified permission model. Analyst has a direct read grant on a table and also receives read access through an active Reporting role. These are two independent stipulated authorization paths. Removing the direct grant leaves one path, so Analyst can still read through Reporting. If that remaining path is also removed, and there are no ownership, public or other privileges, read access is no longer available under the toy model. This is a conceptual example rather than executable SQL. A real check must include the actual database's role activation, inheritance and object rules before concluding that access has been removed.

Illustrative case study

A fictional analytics team retires a service account's temporary reporting access. The administrator removes a direct grant, but a test still succeeds because the account retains a role that permits the same operation. The team examines the intended access scope, adjusts the relevant path and checks the result using the account's actual execution context. It records the outcome rather than only the command's success message. The scenario illustrates the difference between changing one grant and changing effective access. It does not suggest removing unrelated permissions or modifying production access without understanding the affected workflows.

Common misconceptions and mistakes

DCL is not the same as data manipulation language, which concerns operations on records, or data definition language, which commonly concerns database structures. However, vendors do not always classify commands identically. Another mistake is interpreting REVOKE as a universal explicit denial; removing one grant need not override another valid grant. Receiving permission to grant a privilege is also different from merely receiving permission to use it. Finally, a successful permission command does not prove that every intended access path is working or that every unintended path has disappeared.

Business use

The concept helps application owners explain which operations a service needs and review whether database permissions match that need. Describe the required objects and operations concretely rather than asking for unrestricted access as a shortcut. When a role or workflow changes, assess the resulting effective permissions and test representative actions. For an AI application querying business data, distinguish retrieval privileges from modification privileges and understand the actual account used. Clear permission management supports predictable operation, but it must be combined with the application's own behavior and data-use requirements.

Check your understanding

How many read paths remained after the toy direct grant was removed?

Answer: One, through Reporting.

Why could Analyst still read?

Answer: That remaining path independently authorized the operation.

What assumption allowed the final removal to eliminate read access?

Answer: The example explicitly excluded every other source of authorization.

Related terms

SQL
privilege
role
authorization
GRANT
REVOKE

Learn next

Draw a small permission map for one hypothetical role and one object. Include direct grants and role-based paths, then remove one path and determine what remains. Compare the reasoning with the documentation of a chosen database before translating the illustration into actual administrative commands.

Sources

PostgreSQL Global Development Group, REVOKE: https://www.postgresql.org/docs/current/sql-revoke.html The two-path permission calculation, building analogy and service-account case are original educational illustrations. PostgreSQL supplies a concrete documented revocation model; the conceptual example is not a cross-database command recipe and does not claim identical rules across products.

Previous: Data control Next: Data corruption