Now you're pointing out obvious problems. My company deals with data warehouses, we don't really need to delete/update stuff, only insert/select ;) But seriously, those issues can be handled if one doesn't just send plain tuples, but also includes the information about what kind of operations were performed. The receiving side can then use primary keys to process deletes/updates. So the actual solution might become way more flexible, it is only a question of amount of development time put into its implementation... P.S. DDL is never a subject for replication (in normal RDBMS'es). Alex. On Sat, 2007-12-08 at 01:10 -0500, Greg Smith wrote: > On Fri, 7 Dec 2007, Alex Vinogradovs wrote: > > > The documents highlights possible problems with _SQL_ query intercepts. > > I am talking about the actual tuples... i.e. row data rather than the > > SQL requests. > > The first two issues that come to mind are how to deal with a) deletions, > and b) changes to DDL (table creation etc.). Forwarding SQL handles those > but I'm not sure how your suggested scheme would. You should certainly > look at what went into the design of both the existing WAL replication and > tools like Slony to get an idea the full scale of challenges here. > > -- > * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
