Add an option to TRUNCATE instead of DROP CASCADE when --create option set

[nextstopsun]

Is it possible to have an option of doing a TRUNCATE on imported tables instead of DROP CASCADE? I'm loosing a lot of views this way. So I have to truncate tables manually and use an --append option instead of --create, which slows things down very much.

I have a db with a previously imported osm data, but it's easier in this case to reload all the tables instead of updating them with diffs.

What happens if I restrict DROP to the osm2pgsql user? Will the script continue to load in existing tables or throw an error?

[nextstopsun]

@lonvia whoops, sorry - forgot I already wrote this one. Every time I come across this I want to write a github issue:)

[nextstopsun]

Any news here?

[lonvia]

Unlikely to happen unless we switch to configurable pre and post import scripts.

[pnorman]

You'd lose views anyways with the CREATE TABLE AS and renaming at the end of the import.

[nextstopsun]

Matviews won't get hurt in case of truncating instead of dropping. I've checked with revoking DROP from osm2pgsql user - it reports an error in this case.
Is there a way to ignore it and move further?

[lonvia]

I'm closing this. It's too much of a niche requirement with a lot of potential to cause errors unless you know what you are doing.

[nextstopsun]

@lonvia Why is it a niche requirement?
And why do you think adding a nodrop option should cause errors?
It's just a way to control import process.
Currently drop table is hardcoded in create mode and can't be prevented.

[woodpeck]

It is a niche requirement because only people creating views will have that requirement, and that is not part of the usual osm2pgsql usage scenario. It would cause errors if used by someone who doesn't know exactly what they are doing, and where osm2pgsql then attempts to load data into a table that does not have the expected data format. Plus, it would not work anyway, as @pnorman has explained above; you would have to modify not only the TRUNCATE portion but also the sorting afterwards. Finally, to make this remotely efficient you would have to first drop/disable existing indexes. So it is a lot of changes for a use case that benefits very people. It is perhaps something you should make your own special "osm2pgsql with improved matview suport" fork for.