From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:49:00 |
Message-ID: | 5.1.0.14.0.20030506003330.047fc048@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-05 14:51:50 | Re: Transform groups (more FE/BE protocol issues) |
Previous Message | Tom Lane | 2003-05-05 13:45:04 | Re: pg_dump future problem. |