From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump future problem. |
Date: | 2003-05-05 14:58:45 |
Message-ID: | 27747.1052146725@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2003-05-05 15:15:08 | Re: pg_dump future problem. |
Previous Message | Tom Lane | 2003-05-05 14:51:50 | Re: Transform groups (more FE/BE protocol issues) |