On Thu, 23 Feb 2006, Hannu Krosing wrote:

> ?hel kenal p?eval, N, 2006-02-23 kell 15:02, kirjutas Gavin Sherry:
> >
> > The issue, for me, is that there are two ways we could go about
> > implementing this and both have problems.
> >
> > 1) Create triggers on individual system tables.
> >
> > If you wanted to know when a new table was created, when a table was
> > modified or dropped, you would create a trigger on pg_class, I suppose.
> > The problem, though, is that you might want to see what columns a new
> > table has but are they visible yet? It's a bit of a can of worms.
>
> If you want to see the columns, you put triggers on pg_attribute as
> well. How is it different from triggers any other parent-child table
> pair ?

Sure. My point is that people might not want to understand the internals
of the system catalogs when they just want a trigger which puts an entry
in a log table when a new table is added.

> > 2) Create triggers on DDL
>
> That would be more likely CREATE RULE on DDL. In other places we create
> RULES on statements and TRIGGERS on row-level actions.

Not a bad idea.

>
> > It is far from a straight forward concept. The thing is though, the Slony
> > project is not the only project which wants such functionality: the JDBC
> > and other interface providers could greatly benefit because it would mean
> > that their client side metadata caching could be much more efficient.
>
> Just being able to create AFTER triggers (no need to muck with DDL
> commands, just record their effects) would go a long way.

Right. But it's a matter of coming up with a solution which makes everyone
happy and isn't a maintenance nightmare.

Gavin