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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
