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

Being able to put triggers on system tables to record changes together
with ON COMMIT trigger to gather and process this recorded data would
give you 99.9% of needed functionality.

And for slony you would even not need the ON COMMIT trigger, as all
recorded data is processed by another thread anyway.

There will probably be some things that should not be done in triggers
on system tables, but just recording changes to another table is
probably not one of them.

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

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

-------------
Hannu