Quote:
if this must be coded as delete+insert , that would be dangerous if delete is executed but insert failed .
It's not that dangerous, becuse you are supposed to work in a transaction. If the insert fails the delete would be rolled back and the database restored to it's previous state. In any case, I think you should consider mmerder's advice to use a surrogate primary key instead (for example and auto-incrementing number) and keep this hidden (or at least read-only) from the user.
Quote:
SQL allowed to update primmary key
Well... you can do a lot with SQL, but not everything is considered good practice. Changing the primary key will not work as soon as there are rows in other tables that references the primary key that you are updating.