Re: pg_dump future problem. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump future problem.
Date
Msg-id 27747.1052146725@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump future problem.  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: pg_dump future problem.  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> 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.

There is no such statement visible in
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/functions-sequence.html
nor do I find it anywhere else in the current documents.

> It is also 
> not to be relied upon when there are more than one connection to the db 
> updating the sequence.

Any more or less so than either two-parameter SETVAL or the proposed
ALTER TABLE?  I don't see how.

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

It probably would look different if we were starting from scratch
... but we aren't, and I don't see any problems here that are large
enough to justify starting over.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Transform groups (more FE/BE protocol issues)
Next
From: Philip Warner
Date:
Subject: Re: pg_dump future problem.