Re: pg_dump future problem.

Поиск
Список
Период
Сортировка
От Philip Warner
Тема Re: pg_dump future problem.
Дата
Msg-id 5.1.0.14.0.20030506003330.047fc048@mail.rhyme.com.au
обсуждение исходный текст
Ответ на Re: pg_dump future problem.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump future problem.
Список pgsql-hackers
At 09:45 AM 5/05/2003 -0400, Tom Lane wrote:

>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.

In this case I think they have shot themselves in the foot; the docs 
clearly state that setval/3 is for internal pg_dump use only. It is also 
not to be relied upon when there are more than one connection to the db 
updating the sequence.


> > 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.

What I am suggesting is that we make SERIAL sequences more black-box like 
so that we have less reliance on specific implementation details in other 
pieces of code (pg_dump).


>         SELECT setval(serial_seq_name('table', 'column'), 42, true);
>
>and we're not sacrificing anything

I think we are: setval/3 was written to fix one mess with sequences 
(inability to set is_called), now we are suggesting another function to 
patch another (small) hole. ISTM that a more implementation-independant 
approach might be needed. I am not attached to my solution, but I do think 
it's a good idea to look at what would have been done with a 'green fields' 
design, and then ask: can we do it now? Is it worth it?

AFAICT, is_called is just a kludge to allow sequences to attain minval at 
some point; I'm not sure we should be supporting people actually setting it.


>--- nor going through the very
>substantial overhead of creating a new ALTER TABLE variant.

Admittedly it's more complex, but which makes PostgreSQL a better product?
    ALTER TABLE sometable ALTER COLUMN somecolumn SET NEXT 42;
or    SELECT setval(serial_seq_name('sometable', 'somecolumn'), 42, true);





----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump future problem.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Transform groups (more FE/BE protocol issues)