Search Postgresql Archives

Re: Triggers inherited?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi -

I too have encountered this issue. The work around that I created was to have every table have a set of 3 cooresponding functions that know how to 1) create the table; 2) create triggers for the table; 3) create indexes for the table. By doing so, I then am able to use a lazy partitioning technique, such that an insert trigger determines if the necessary partition exists, and if not, calls the functions needed to create it. It keeps the SQL needed for a table in a single location (DRY), and is flexible enough to be used for creating virgin databases as well as updating existing databases.

- Marc

On Thu, 22 Feb 2007, Bertram Scharpf wrote:

Hi,

it is very inconvenient for me that triggers aren't inherited:

 create table watch (
     mod timestamp with time zone default '-infinity' not null
 );

 create function update_mod() returns trigger ...

 create trigger update_mod before insert or update on watch
     for each row execute procedure update_mod();

 create table some  ( ... ) inherits (watch);
 create table other ( ... ) inherits (watch);


Is this behaviour to be implemented at any point of time in
the future? Could it be advisible to write the patch? Or is
it just too easy to emulate it?

Reimplemeting a trigger for each descending table definitely
dosn't satisfy me.

Thanks in advance,

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux