Thread: Triggers inherited?

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

Bertram Scharpf wrote:
> Hi,
>
> it is very inconvenient for me that triggers aren't inherited:

Foreign keys too (which are a special type of trigger of course).

> 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?

If you have the time and skills, I think many people would be interested
in a patch to handle this.

You will want to check the todo list, developers website and FAQ (and of
course the internals section of the manuals) then discuss things on the
hackers mailing list.
   http://www.postgresql.org/docs/faqs.TODO.html
   http://www.postgresql.org/developer/
   http://www.postgresql.org/docs/faqs.FAQ_DEV.html
   http://developer.postgresql.org/
--
   Richard Huxton
   Archonet Ltd

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
>

Hi,

Am Freitag, 23. Feb 2007, 07:10:06 +0000 schrieb Richard Huxton:
> Bertram Scharpf wrote:
> >it is very inconvenient for me that triggers aren't inherited:
>
> Foreign keys too (which are a special type of trigger of course).
>
> >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?
>
> If you have the time and skills, I think many people would be interested
> in a patch to handle this.

I successfully wrote some patches to `plruby' and to
`ruby-postgres'. Seems that I have to give it a try. Don't
expect too much too near.

Anyhow: Thank you very much for the tip. At least I know I'm
not the only one thinking about these things.

Bertram


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