Re: pg_dump future problem.
От | Tom Lane |
---|---|
Тема | Re: pg_dump future problem. |
Дата | |
Msg-id | 27415.1052142304@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump future problem. (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: pg_dump future problem.
|
Список | pgsql-hackers |
Philip Warner <pjw@rhyme.com.au> writes: > At 10:10 AM 4/05/2003 -0400, Tom Lane wrote: >> And the is_called flag fits into this where? > My recollection is that is_called is used to cover the boundary case where > the 'current' value should not be incremented before being returned, but my > memory is hazy. If this is the case, can we not just set it to true and set > the value to (next - 1) unless (next - 1) < minv, in which case we set it > to minv and set is_called to false? This would fail to cover the case where the user has used setval() to set is_called false and last_value to something other than minv. > Note that for the purpose of serial values we do not need to set the > sequence exactly as it was internally, we just need to make sure that the > next allocated value will be what we expect. I disagree with the notion that pg_dump need not dump legal configurations of the database. ISTM the real issue here is that we don't want pg_dump dumps to hard-wire knowledge of the algorithm for deriving a sequence name from a table and column name. Why not attack that straightforwardly: provide a backend function that computes one from the other? Then the SETVAL calls could become something like SELECT setval(serial_seq_name('table', 'column'), 42, true); and we're not sacrificing anything --- nor going through the very substantial overhead of creating a new ALTER TABLE variant. regards, tom lane
В списке pgsql-hackers по дате отправления: