RE: Logging for sequences
От | Mikheev, Vadim |
---|---|
Тема | RE: Logging for sequences |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D31D2@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответ на | Logging for sequences ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Список | pgsql-hackers |
> Vadim, Philip changed that part of pg_dump on my advice. The idea was > to try to do the right thing for sequences when loading schema only or > data only. Analogously to loading data into a pre-existing table, we > felt that a data dump ought to be able to restore the current state of > an already-existing sequence object. Hence it should use setval(). Tables have many records but sequences single one. So, I don't see what would be wrong if we would drop/recreate sequences in data-only mode - result would be the same as with setval: required state of sequence. Ok, ok - sequence' OID would be different. ... > My inclination is to leave pg_dump as it stands, and change > do_setval's error check. We could rip out the check entirely, or we > could modify the code so that a setval() is allowed for a sequence > with cache > 1 only if it's the new three-parameter form of setval(). > That would allow pg_dump to do its thing without changing the behavior > for existing applications. Also, we can certainly make setval() flush > any cached nextval assignments that the current backend is holding, even > though we have no easy way to clean out cached values in other backends. > > Comments? I don't object any approach. Vadim
В списке pgsql-hackers по дате отправления: