Handling Changed and Deleted Objects

[lonvia]

When processing updates, osm2pgsql will handle deleted objects by simply deleting them from the database. A changed object is handled as if it was deleted and a new object created after that. But users often want to do some extra processing when an object is deleted or changed.

Currently this can be handled by adding database triggers that do something else instead of the delete. But that is somewhat cumbersome and, for changed objects, we have to fit the “delete” and the “insert” together again to find out that we had a “change” originally, something we knew at the start of the processing chain, but that information is lost once we are inside the database.

We might need some extra callbacks into the Lua code for this and/or change the DELETE/COPY we are doing now into some kind of “UPSERT”.

[pnorman]

I've looked into something other than delete/copy a few times and the problem I always run into is the lack of primary key.

Conceptually the problem is a bit broader, because an OSM object can result in one or multiple database rows, and the number of rows can change in an update.

Because a modify can change the number of rows we have to use an insert or delete somewhere behind the scenes. I don't see that a custom function would help either, since the database triggers are still going to catch the insert and delete.

If you have a primary key it becomes fairly easy - all inserts and modifications in append mode become an INSERT ... ON CONFLICT ...