Alex Vinogradovs wrote:
> 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...
>
If I understand what you are saying, this is how Replicator already does
replication (www.commandprompt.com). Inserts replication transactional
data, where updates and deletes replicate the low level command (what
was deleted/updated not the actual DML).
Joshua D. Drake
> 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
>
> ---------------------------(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
>