Bird
Raised Fist0
PostgreSQLquery~10 mins

RAISE for notices and exceptions in PostgreSQL - Interactive Code Practice

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
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to raise a notice message in PostgreSQL.

PostgreSQL
RAISE [1] 'This is a notice message';
Drag options to blanks, or click blank then click option'
AEXCEPTION
BWARNING
CNOTICE
DINFO
Attempts:
3 left
💡 Hint
Common Mistakes
Using EXCEPTION instead of NOTICE causes the code to stop with an error.
Using INFO raises an INFO message instead of NOTICE.
2fill in blank
medium

Complete the code to raise an exception with a custom error message.

PostgreSQL
RAISE [1] 'Custom error occurred';
Drag options to blanks, or click blank then click option'
ANOTICE
BLOG
CWARNING
DEXCEPTION
Attempts:
3 left
💡 Hint
Common Mistakes
Using NOTICE or WARNING will not stop execution as expected.
Using LOG only logs the message but does not raise an error.
3fill in blank
hard

Fix the error in the code to raise a warning message.

PostgreSQL
RAISE [1] 'This is a warning';
Drag options to blanks, or click blank then click option'
AWARNING
BWARN
CEXCEPTION
DNOTICE
Attempts:
3 left
💡 Hint
Common Mistakes
Using WARN instead of WARNING causes syntax error.
Using EXCEPTION raises an error, not a warning.
4fill in blank
hard

Fill both blanks to raise a notice with a variable value.

PostgreSQL
RAISE [1] 'Value is: %', [2];
Drag options to blanks, or click blank then click option'
ANOTICE
BEXCEPTION
Cmy_var
D42
Attempts:
3 left
💡 Hint
Common Mistakes
Using EXCEPTION stops execution instead of showing a notice.
Passing a literal number instead of the variable loses dynamic value.
5fill in blank
hard

Fill all three blanks to raise an exception with a formatted message including a variable.

PostgreSQL
RAISE [1] 'Error code %: %', [2], [3];
Drag options to blanks, or click blank then click option'
ANOTICE
Berror_code
Cerror_message
DEXCEPTION
Attempts:
3 left
💡 Hint
Common Mistakes
Using NOTICE instead of EXCEPTION does not stop execution.
Swapping variable order changes the message meaning.

Practice

(1/5)
1. What does the RAISE NOTICE statement do in PostgreSQL?
easy
A. It silently logs a message without showing it to the user.
B. It stops the code execution and returns an error.
C. It sends a message to the client but continues running the code.
D. It restarts the current transaction automatically.

Solution

  1. Step 1: Understand RAISE NOTICE behavior

    RAISE NOTICE sends an informational message to the client but does not stop the execution.
  2. Step 2: Compare with other RAISE levels

    Unlike EXCEPTION, which stops execution, NOTICE only shows a message and continues.
  3. Final Answer:

    It sends a message to the client but continues running the code. -> Option C
  4. Quick Check:

    RAISE NOTICE = message without stopping [OK]
Hint: NOTICE shows messages but never stops code [OK]
Common Mistakes:
  • Confusing NOTICE with EXCEPTION stopping code
  • Thinking NOTICE hides messages
  • Assuming NOTICE restarts transactions
2. Which of the following is the correct syntax to raise a warning message in a PostgreSQL function?
easy
A. RAISE WARNING 'This is a warning';
B. RAISE WARN 'This is a warning';
C. RAISE WARNNING 'This is a warning';
D. RAISE WARN_MSG 'This is a warning';

Solution

  1. Step 1: Recall correct RAISE syntax for warnings

    The correct keyword is WARNING, not WARN or other variants.
  2. Step 2: Validate syntax correctness

    RAISE WARNING 'message'; is the valid syntax to raise a warning message.
  3. Final Answer:

    RAISE WARNING 'This is a warning'; -> Option A
  4. Quick Check:

    RAISE WARNING = correct syntax [OK]
Hint: Use full word WARNING, not abbreviations [OK]
Common Mistakes:
  • Using 'WARN' instead of 'WARNING'
  • Misspelling WARNING as WARNNING
  • Inventing unsupported keywords like WARN_MSG
3. Consider this PostgreSQL PL/pgSQL block:
DO $$
BEGIN
  RAISE NOTICE 'Step 1';
  RAISE WARNING 'Step 2';
  RAISE EXCEPTION 'Step 3';
  RAISE NOTICE 'Step 4';
END $$;

What will be the output?
medium
A. Step 1 and Step 4 notices print, but warning and exception are ignored.
B. All four messages print: Step 1, Step 2, Step 3, Step 4.
C. Only Step 3 error message is shown, others are ignored.
D. Step 1 (notice), Step 2 (warning), then error 'Step 3', and stops before Step 4.

Solution

  1. Step 1: Trace the RAISE statements in order

    RAISE NOTICE 'Step 1' prints a message and continues.
  2. Step 2: Understand RAISE WARNING and EXCEPTION effects

    RAISE WARNING 'Step 2' prints a warning and continues. RAISE EXCEPTION 'Step 3' raises an error and stops execution immediately.
  3. Step 3: Check if Step 4 runs

    Since EXCEPTION stops execution, RAISE NOTICE 'Step 4' does not run.
  4. Final Answer:

    Step 1 (notice), Step 2 (warning), then error 'Step 3', and stops before Step 4. -> Option D
  5. Quick Check:

    EXCEPTION stops code after Step 3 [OK]
Hint: EXCEPTION stops code; notices/warnings do not [OK]
Common Mistakes:
  • Assuming all messages print despite EXCEPTION
  • Thinking WARNING stops execution
  • Ignoring that EXCEPTION halts code immediately
4. You wrote this code inside a PostgreSQL function:
RAISE EXCEPTION 'Error: %', message;

But it causes an error: "ERROR: column "message" does not exist". What is the likely problem?
medium
A. The variable 'message' is not declared or out of scope.
B. RAISE EXCEPTION cannot use placeholders like '%'.
C. You must use RAISE WARNING instead of EXCEPTION for variables.
D. The syntax requires double quotes around 'message'.

Solution

  1. Step 1: Understand the error message

    The error says column "message" does not exist, meaning 'message' is treated as a column or variable but is undefined.
  2. Step 2: Check variable declaration and scope

    In PL/pgSQL, variables must be declared before use. If 'message' is not declared or out of scope, this error occurs.
  3. Final Answer:

    The variable 'message' is not declared or out of scope. -> Option A
  4. Quick Check:

    Undefined variable causes this error [OK]
Hint: Declare variables before using in RAISE [OK]
Common Mistakes:
  • Thinking placeholders '%' are invalid
  • Using RAISE WARNING instead of EXCEPTION for variables
  • Adding quotes around variable names incorrectly
5. You want to write a PostgreSQL function that checks if a user age is below 18 and raises an exception with a custom message including the age. Which code snippet correctly does this?
hard
A. IF age < 18 THEN RAISE EXCEPTION 'User age % is too young' || age; END IF;
B. IF age < 18 THEN RAISE EXCEPTION 'User age % is too young', age; END IF;
C. IF age < 18 THEN RAISE EXCEPTION MESSAGE = 'User age ' || age || ' is too young'; END IF;
D. IF age < 18 THEN RAISE EXCEPTION 'User age % is too young', 'age'; END IF;

Solution

  1. Step 1: Understand RAISE EXCEPTION with placeholders

    RAISE EXCEPTION supports printf-style placeholders like % and variables as arguments.
  2. Step 2: Check each option's correctness

    IF age < 18 THEN RAISE EXCEPTION 'User age % is too young', age; END IF; correctly uses the % placeholder followed by the variable age as an argument.
    IF age < 18 THEN RAISE EXCEPTION 'User age % is too young' || age; END IF; incorrectly concatenates the variable to the format string, resulting in an unreplaced % and a runtime format error.
    IF age < 18 THEN RAISE EXCEPTION MESSAGE = 'User age ' || age || ' is too young'; END IF; omits the required USING keyword before MESSAGE=, causing a syntax error.
    IF age < 18 THEN RAISE EXCEPTION 'User age % is too young', 'age'; END IF; passes the string literal 'age' instead of the variable.
  3. Final Answer:

    IF age < 18 THEN RAISE EXCEPTION 'User age % is too young', age; END IF; -> Option B
  4. Quick Check:

    Use % and variable for dynamic messages [OK]
Hint: Use % placeholder with variable, not string 'age' [OK]
Common Mistakes:
  • Concatenating strings instead of using placeholders
  • Passing variable name as string instead of variable
  • Using incorrect RAISE EXCEPTION syntax