Question

How is trigger function different from ‘regular’ functions? And is it absolutely necessary in creating a trigger?

For example, in this case:

-- Trigger function
CREATE FUNCTION update_record_trigger_function() RETURNS trigger
LANGUAGE plpgsql
AS $update_record_trigger_function$
BEGIN
  PERFORM update_record(NEW.oid); -- helper function ... 
  RETURN NEW;
END
$update_record_trigger_function$;

-- Trigger for updating latest clicks for posts
CREATE TRIGGER update_latest_record
AFTER INSERT OR UPDATE ON record
FOR EACH ROW
EXECUTE PROCEDURE update_record_trigger_function();

Would it not be simpler to (or is it possible to do):

-- Trigger for updating latest clicks for posts
CREATE TRIGGER update_latest_record
AFTER INSERT OR UPDATE ON record
FOR EACH ROW
PERFORM update_record(NEW.oid); -- syntactically not right but along this idea

I wasn’t able to find any document with examples of ‘skipping trigger function’ or one that explaining how trigger function is special and necessary for triggers?

Answer 1

PostgreSQL separates the “trigger function” from the trigger definition for quite a few reasons:

• Trigger functions can be written as generic functions that can work on many different tables, so you can add the same trigger function as a trigger to many different tables. This eases maintenance.

• Trigger functions can take parameters that allow them to adapt to specific column names or other characteristics of the table you apply them to. This makes it practical to write generic, re-usable trigger functions where you otherwise could not do so, so you often don’t need to repeat the code in multiple places. See EXECUTE ... USING and the format function with its %L and %I format-specifiers.

• PostgreSQL tries very hard not care what programming language your functions are written in . They could be PL/PgSQL, Python, Perl, C, or MyWackyPluginLanguage. If it didn’t separate trigger function from trigger definition this would be harder to achieve.

The shorthand you describe is not supported in PostgreSQL, though some other database systems provide something very much like what you’ve shown. You essentially want to be able to define a trigger function as an inline expression. This isn’t supported. There’s never been a pressing need for it so nobody’s implemented it.

If such a feature were added in future – and I’m not aware of any plans to do so – it would probably be done using a PL/PgSQL DO block that was contextually interpreted as a trigger, something like (not legal syntax):

CREATE TRIGGER update_latest_record
AFTER INSERT OR UPDATE ON record
FOR EACH ROW DO $$ PERFORM update_record(NEW.oid); RETURN NEW; $$;

That way the parser wouldn’t need to understand PL/PgSQL constructs, we’d just have to teach it to understand FOR EACH ROW DO [string literal body of function] as an alternative to FOR EACH ROW EXECUTE PROCEDURE proc_name(args) and then invoke the PL/PgSQL subsystem to process the trigger literal.

In practice Pg would probably just generate an ordinary trigger function and add a reference to it from the trigger so it’s dropped if the trigger was dropped, making this a just convenience macro, just like SERIAL is a convenience macro for an INTEGER field with a DEFAULT nextval(...) and a generated SEQUENCE owned by the table with the SERIAL field. In particular, pg_dump would probably output it as if you’d defined a separate trigger function and trigger, rather than used the shorthand.

Honestly, I doubt anything like this will ever be added, but if you can provide sufficiently convincing use cases you might if you’re really lucky interest someone in it. Most likely you’ll only get anywhere with such a proposal (“allow DO blocks to be used as trigger procedures”) if you’re willing to back it with funding for the time required to implement the feature.