Consider a Supabase database table with a trigger that runs a function after an INSERT operation. What is the expected behavior of this trigger?
CREATE FUNCTION log_insert() RETURNS trigger AS $$ BEGIN INSERT INTO audit_log(table_name, operation) VALUES (TG_TABLE_NAME, 'INSERT'); RETURN NEW; END; $$ LANGUAGE plpgsql;
CREATE TRIGGER after_insert_trigger AFTER INSERT ON users FOR EACH ROW EXECUTE FUNCTION log_insert();Think about when AFTER INSERT triggers run and what RETURN NEW means.
AFTER INSERT triggers run after the row is inserted. The function logs the operation and returns the new row unchanged.
You want to ensure data integrity by checking values before they are saved in a Supabase table. Which trigger timing should you use?
Consider when you want to stop bad data from entering the table.
BEFORE INSERT triggers run before the data is saved, allowing validation and modification or rejection.
A Supabase trigger calls an external API to notify another system after data changes. What is a potential security risk?
Think about sensitive information in trigger code.
Embedding API keys or secrets in trigger functions risks exposure and unauthorized access.
Given a BEFORE INSERT trigger function in Supabase that returns NULL, what happens to the insert operation?
CREATE FUNCTION block_insert() RETURNS trigger AS $$ BEGIN RETURN NULL; END; $$ LANGUAGE plpgsql; CREATE TRIGGER before_insert_block BEFORE INSERT ON orders FOR EACH ROW EXECUTE FUNCTION block_insert();
Check what RETURN NULL means in BEFORE triggers.
Returning NULL in a BEFORE trigger cancels the operation, so the row is not inserted.
You have a high-traffic Supabase table with triggers that perform complex calculations. What is the best way to avoid slowing down database operations?
Think about how to keep database operations fast and responsive.
Triggers run inside transactions and can slow down operations. Offloading work to background jobs improves performance and scalability.
