> I don't understand this if it's calling option 2 the monolithic > implementation. I was intending that the values be permanent tokens if > you like, so that ZERO rewriting would be required for any types of > modification. So I don't see where locking comes in. I don't want > rewriting either.
I think you are not considering existing btree indexes here (for the reordering case) ? So +1 on a solution that has naturally sorting keys (e.g. your 1). Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
