Bird
Raised Fist0
PostgreSQLquery~30 mins

Column-level permissions in PostgreSQL - Mini Project: Build & Apply

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Column-level permissions in PostgreSQL
📖 Scenario: You are managing a company database where sensitive employee information must be protected. You want to allow a user to see only certain columns of the employees table, such as their names and departments, but not their salaries.
🎯 Goal: Create a PostgreSQL setup where a user has permission to select only specific columns from the employees table, demonstrating column-level permissions.
📋 What You'll Learn
Create a table called employees with columns id, name, department, and salary.
Create a role called limited_user.
Grant SELECT permission on only the name and department columns of the employees table to limited_user.
Revoke any other SELECT permissions on the employees table from limited_user.
💡 Why This Matters
🌍 Real World
Column-level permissions help protect sensitive data in databases by restricting access to only necessary information for certain users.
💼 Career
Database administrators and developers often need to implement fine-grained access control to comply with privacy laws and company policies.
Progress0 / 4 steps
1
Create the employees table
Create a table called employees with columns id as integer primary key, name as text, department as text, and salary as integer.
PostgreSQL
Hint

Use CREATE TABLE with the specified columns and types.

2
Create the role limited_user
Create a role called limited_user without login privileges.
PostgreSQL
Hint

Use CREATE ROLE limited_user NOLOGIN; to create the role.

3
Grant column-level SELECT permissions
Grant SELECT permission on only the name and department columns of the employees table to the role limited_user.
PostgreSQL
Hint

Use GRANT SELECT (name, department) ON employees TO limited_user; to grant column-level permissions.

4
Revoke other SELECT permissions
Revoke any other SELECT permissions on the employees table from limited_user to ensure only the specified columns are accessible.
PostgreSQL
Hint

Use REVOKE SELECT ON employees FROM limited_user; to remove full table select permissions.

Practice

(1/5)
1. What does column-level permission in PostgreSQL control?
easy
A. Access to server configuration files
B. Access to entire tables only
C. Access to database schemas
D. Access to specific columns in a table

Solution

  1. Step 1: Understand the concept of column-level permissions

    Column-level permissions allow control over which columns a user can see or modify in a table.
  2. Step 2: Compare with other access types

    Other options refer to broader or unrelated access controls, not specific columns.
  3. Final Answer:

    Access to specific columns in a table -> Option D
  4. Quick Check:

    Column-level permission = Access to specific columns [OK]
Hint: Column-level means controlling access per column, not whole table [OK]
Common Mistakes:
  • Confusing column-level with table-level permissions
  • Thinking it controls schema or server access
  • Assuming it controls row-level access
2. Which of the following is the correct syntax to grant SELECT permission on column email of table users to user alice?
easy
A. GRANT SELECT(email) ON users TO alice;
B. GRANT SELECT ON users TO alice(email);
C. GRANT SELECT ON users(email) TO alice;
D. GRANT SELECT TO alice ON users(email);

Solution

  1. Step 1: Recall PostgreSQL syntax for column-level GRANT

    The correct syntax is GRANT SELECT (email) ON users TO alice; (parentheses after privilege).
  2. Step 2: Match options with syntax

    GRANT SELECT(email) ON users TO alice; matches the correct syntax exactly, others misplace keywords or parentheses.
  3. Final Answer:

    GRANT SELECT(email) ON users TO alice; -> Option A
  4. Quick Check:

    GRANT SELECT(column) ON table TO user [OK]
Hint: GRANT SELECT(column) ON table TO user is correct syntax [OK]
Common Mistakes:
  • Placing column name after TO user
  • Putting column inside ON table()
  • Misordering keywords in the statement
3. Given the table employees(id, name, salary), if user bob has SELECT permission only on id and name, what will be the result of SELECT * FROM employees; executed by bob?
medium
A. Only id and name columns with data, salary as NULL
B. All columns with actual data
C. Error: permission denied
D. Only salary column with data

Solution

  1. Step 1: Understand column-level permission effect on SELECT *

    User can see columns they have permission for; restricted columns appear as NULL.
  2. Step 2: Apply to given columns

    Bob has permission on id and name, so salary shows as NULL.
  3. Final Answer:

    Only id and name columns with data, salary as NULL -> Option A
  4. Quick Check:

    Restricted columns show NULL, not error [OK]
Hint: Restricted columns appear as NULL, not error [OK]
Common Mistakes:
  • Expecting a permission denied error
  • Assuming all columns show data
  • Thinking restricted columns are hidden completely
4. You run the command GRANT SELECT ON employees(name, salary) TO carol; but get a syntax error. What is the likely cause?
medium
A. Column names must be in double quotes
B. Cannot grant permissions on multiple columns at once
C. Column list in parentheses must precede the table name
D. User carol does not exist

Solution

  1. Step 1: Check syntax for GRANT with multiple columns

    Correct syntax is GRANT SELECT (name, salary) ON employees TO carol;
  2. Step 2: Identify error in command

    Command incorrectly places column list after table name; column list must follow SELECT before ON.
  3. Final Answer:

    Column list in parentheses must precede the table name -> Option C
  4. Quick Check:

    GRANT SELECT (col1, col2) ON table TO user [OK]
Hint: Columns inside parentheses after SELECT before ON table [OK]
Common Mistakes:
  • Placing column list after table name
  • Forgetting parentheses around columns
  • Assuming multiple columns need separate GRANTs
5. You want to allow user dave to update only the phone column in the contacts table but not others. Which sequence of commands correctly achieves this?
hard
A. GRANT UPDATE(phone) ON contacts TO dave; REVOKE UPDATE ON contacts FROM dave;
B. REVOKE UPDATE ON contacts FROM dave; GRANT UPDATE(phone) ON contacts TO dave;
C. GRANT UPDATE ON contacts TO dave; REVOKE UPDATE(phone) ON contacts FROM dave;
D. GRANT UPDATE(phone) ON contacts TO dave;

Solution

  1. Step 1: Remove any existing full UPDATE permission

    First revoke any broad UPDATE permission to avoid conflicts.
  2. Step 2: Grant UPDATE permission only on the phone column

    Then grant UPDATE on the specific column to limit access.
  3. Final Answer:

    REVOKE UPDATE ON contacts FROM dave; GRANT UPDATE(phone) ON contacts TO dave; -> Option B
  4. Quick Check:

    Revoke broad then grant column-level UPDATE [OK]
Hint: Revoke broad permission before granting column-level update [OK]
Common Mistakes:
  • Granting column-level without revoking broad permission
  • Revoking column-level instead of broad permission
  • Assuming single GRANT is enough if broad permission exists