Re: pg_dump future problem.

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

In response to

Responses

Browse pgsql-hackers by date

  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.