Update pk seq
Thank you for the effort you put into this, but I don't have any plans to merge this functionality, as it seems to me something that would be a better fit for your own library code.
 The use case for this is actually very common. Many, if not most, DBs have some reference tables that are populated with an initial set of values and later added to, and those tables are usually the target of foreign key relations. The peewee docs even contain a section on how to do it, "Manually specifying primary keys".  If a peewee user follows the docs, then after re-activating auto_increment in a Postgresql database, as instructed by the docs, they are going to encounter a duplicate key constraint violation, unless they do something like what I've done. If the  sequence update is not done by peewee then the user must code it as a special case for Postgresql if they wish to target different DBs. 

For a feature as frequently used as auto-increment, and with such a troublesome incompatibility between Postgresql and the other back-end DBs, isn't it worth one method on the model to keep peewee client code DB neutral? 
 > The use case for this is actually very common

I'd beg to differ, as in the 4+ years peewee's been around, you're the first to ask for a sequence updating helper.

My stance is that relying on particular values for auto-incremented, sequence-backed columns is an anti-pattern. I understand that maybe you're restoring data, but in the very rare cases I've done that all I had to do was restore the data then set the currval of the sequence -- it was a one-time operation, just another part of restoring from backup.

The docs you've referenced even emphasize that this is a one-time type operation:

> To handle this on a **one-off** basis, you can simply tell peewee to turn off auto_increment during the import
 I agree that it's a one-off operation, though possibly one time for each new deployment. But when you are finished with it the DB might be broken (if it's postgresql), or it might not. The docs don't mention that your DB might be broken, and there's no database neutral code that you can write to make sure that it's fixed. That's all I'm trying to create, the simplest possible uniform way to fix any DB after inserting explicit keys into an auto-increment table. 

New method to force the DB to ensure that the next auto-generated key will be greater than any existing key, including explicitly inserted keys. On sqlite and MySQL this happens automatically, so the method is a no-op. For Postgresql it provides a canned version of a nice query to update the sequence, saving peewee users from having to write it themselves. 

This might possibly be simplified and better integrated by having a method to turn auto_increment on/off rather than just setting the attribute on the model. Then this method could be run whenever auto_increment is explicitly activated. 
