# Dynamic Triggers in PLpgSQL

DevFeed: [Dynamic Triggers in PLpgSQL](<https://devfeed.tech/articles/dynamic-triggers-in-plpgsql-34400.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2010/11/dynamic-triggers-in-plpgsql/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2010-11-24T15:45:00Z

Content type: tutorial

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [function](<https://devfeed.tech/topics/function.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [developer](<https://devfeed.tech/tags/developer.md>), [function](<https://devfeed.tech/tags/function.md>), [implementing](<https://devfeed.tech/tags/implementing.md>), [triggers](<https://devfeed.tech/tags/triggers.md>)

## AI overview

This article explores implementing dynamic triggers in PL/pgSQL, including reusing the same trigger function across multiple tables and handling a dynamic column name. The author describes the approach as difficult, unconventional, and preliminary, with slow performance in initial tests.

## Source excerpt

You certainly know that implementing dynamic triggers in PLpgSQL is impossible. But I had a very bad night, being up from as soon as 3:30 am today, so that when a developer asked me about reusing the same trigger function code from more than one table and for a dynamic column name, I didn't remember about it being impossible. Here's what happens in such cases, after a long time on the problem (yes, overall, that's a slow day). Note that I'm abusing the (record_literal).* notation a lot in there, and even the (record_literal).column_name too.