Re: [GENERAL] pg_migrator not setting values of sequences?
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] pg_migrator not setting values of sequences? |
Дата | |
Msg-id | 200907160428.n6G4SlO11897@momjian.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] pg_migrator not setting values of sequences? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> The most effective solution might be to revert the change in pg_migrator > >> and instead have pg_dump interpret --binary-upgrade --schema-only to > >> include the data for sequences. It seems ugly as sin though :-( > > > Uh, how is this going to behave in 8.5? Do we still dump sequences, and > > if so, aren't we heading down the road of dumping stuff only because a > > previous release needed it? > > In 8.5 we'll probably have it go over to treating sequences the same as > other user tables. What, do you think that'll be the only change > required in pg_migrator's behavior between 8.4 and 8.5? I think it'll > more likely be down in the noise ... I am just worried about jerking pg_dump around as pg_migrator's needs change. > > Can we run a query that just shifts columns around in the sequence heap > > files we migrated? > > Nope. That's not exposed at the SQL level, even if we allowed ALTER > TABLE on sequences (which I sure hope we don't). Ah, I see what you mean: test=> create sequence xx;seCREATE SEQUENCEtest=> select * from xx; sequence_name | last_value | start_value | increment_by| max_value | min_value | cache_value | log_cnt | is_cycled |is_called---------------+------------+-------------+--------------+---------------------+-----------+-------------+---------+-----------+----------- xx | 1 | 1 | 1 |9223372036854775807 | 1 | 1 | 1 | f | f(1 row)test=> update xx set last_value = 3;ERROR: cannot change sequence "xx" -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: