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@gregsmith.com http://www.gregsmith.com Baltimore, MD
