Re: pg_dump future problem.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump future problem.
Дата
Msg-id 27926.1052148148@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:
> Good point. It's only in the source code. I thought I had updated the docs 
> as well...

Actually, I think the sequence of events was that we neglected to remove
the statement in the source code when we fixed the documentation.
3-parameter setval is documented because it solves a problem that users
have --- pg_dump is not the only application that needs to do this.

> My recollection is that setting is_called is more fragile than just setting 
> the sequence value, so it not wise to use in general.

Doesn't look that way to me; we're setting several fields of the
sequence record no matter what.  Perhaps your recollection predates
Vadim's last rewrite of the sequence code?

> I'm not actually suggesting starting over. Just presenting a nicer 
> interface and fixing a bug in the process, rather than building yet another 
> user-visible function as a band-aid solution.

But the proposed "nicer interface" *introduces* a bug, namely the
inability to preserve is_called, which is exactly the pg_dump bug
that 3-parameter setval was invented to fix.  I do not want to go
backwards in the name of a "nicer interface".
        regards, tom lane



В списке pgsql-hackers по дате отправления:

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