3 ms·
I think one of the quirks you can run in to with MySQL's implementation is that even the DB decides to do an update, you end up burning an auto incremented key.
by luckycharms810 11y ago
I think one of the quirks you can run in to with MySQL's implementation is that even the DB decides to do an update, you end up burning an auto incremented key. Curious to see what PG ends up doing here.
- pilif 11y ago> you end up burning an auto incremented key. Curious to see what PG ends up doing here I haven't tried, but Postgres always uses values in sequences in similar cases. The good news is that there are so many values in a 64 bit sequence that this really shouldn't matter. I much prefer some values in sequences to be not used over even the tiniest possibility of a value being used twice accidentally.
- anarazel 11y agoYou pretty much have to do so. The conflict could be on the column with the default value after all. And obviously you can't just rollback the sequence/autoincrement value after deciding to update because that'd either require locking the sequence for the duration (horrible for concurrency) or would pose problems with other sessions already having used further values.