On Fri, 2004-08-20 at 09:29, Jan Wieck wrote:
> On 8/20/2004 10:08 AM, Jeremiah Jahn wrote:
> 
> > On Thu, 2004-08-19 at 14:41, Jan Wieck wrote:
> >> On 8/19/2004 3:36 PM, Jeremiah Jahn wrote:
> >> 
> >> > If you could, wouldn't that fix the problem? So, would it be worthwhile
> >> > to be able to put a trigger on at least the LO table, maybe even other
> >> > system tables (for schema replication). I assume that it's a performance
> >> > issue that has prevented this before.
> >> 
> >> No. The issue is that system catalog updates most of the time don't go  
> >> through the executor, but call heap_insert(), heap_update and 
> >> heap_delete() directly. The trigger mechanism is in the executor.
> > 
> > 'System catalog' updates refers to schema changes right, and not lo
> > updates? If that is the case, then what prevents adding a hook to enable
> > triggers on the lo table. As for changes to the schema , why not just
> > push them through the executor all of the time, instead of some of the
> > time?
> 
> Take a look at src/backend/storage/large_object/inv_api.c and then come 
> up with a design how to add trigger capabilities to that. This design 
> should preferrably include a way to create/modify/delete large objects 
> through the SQL querylanguage or it would impose a roadblock for one of 
> the future plans for Slony-I.
Correct me if I'm wrong, but don't you want to keep large objects out of
the SQL, due to parsing overhead? Bytea, and text are capable of being
used in place of LOs but the last time I tried that, things were so slow
that it turned out to be useless. There for isn't it safe to say that
the best you can ever do is to only pass a reference (OID) to the LO and
not the actual LO itself in the SQL?

As to the other question:
Could you replace simple_heap_update/insert/delete with
ExecInsert/Update/Delete, and leave most everything else untouched. Off
the top of my head, isn't the only thing we are looking for the event of
a data change to the pg_large_object table, and then pass said change on
to the slave? I assume the salve will need to understand that it is
being passed an LO so that it doesn't try to insert the exact same OID
numbers in to the pg_large_object table, or is it safe to assume that
the OID numbers on the child will be the same as the parent?

> 
> We have some time for the whole design because this is a feature that 
> cannot be added by working on Slony alone. It needs modifications in the 
> PostgreSQL backend. Since we will not get those into any existing, 
> released version of PostgreSQL, this feature would be restricted to 
> PostgreSQL 8.1 and newer. 8.0 is already in feature freeze.
> 
> 
> Jan
> 
> > 
> >> 
> >> 
> >> Jan
> >> 
> >> > 
> >> > -jj-  
> >> > 
> >> > On Thu, 2004-08-19 at 13:29, Doug McNaught wrote:
> >> >> Jeremiah Jahn <jeremiah at cs.earlham.edu> writes:
> >> >> 
> >> >> > So it's not possible to just trigger off of the pg_large_object table?
> >> >> 
> >> >> No, you can't put triggers on system tables.
> >> >> 
> >> >> -Doug
-- 
Jeremiah Jahn <jeremiah at cs.earlham.edu>