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.  (Philip Warner <pjw@rhyme.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Why are triggers semi-deferred?
Следующее
От: Philip Warner
Дата:
Сообщение: Re: pg_dump future problem.