Re: pg_dump and sequences - RFC

Philip Warner <pjw@rhyme.com.au> writes:
> My inclinations is do do the following:

> - Issue 'CREATE SEQUENCE...Initial Value 1...' in OID order
> - Issue 'SELECT SETVAL...' at end of data load.

> This means that a schema-only restore will hgave all sequences set up with
> initial value = 1, and a data-only restore will have sequences set
> 'correctly'.

Seems reasonable, except you should not necessarily use 1; that could
be outside the defined range of the sequence object.  Use its min_value
instead.

It's too bad the sequence object doesn't save the original starting
value, which is what the schema-only restore REALLY should restore.
The min_value is probably close enough for practical purposes ... not
sure that it's worth adding an original_value column just for this.
(It'd be a simple enough change in terms of the code, but I wonder if
it might create compatibility problems for applications that look at
the contents of sequences.)


> Also, I'd be interested to know what the purpose of 'SELECT NEXTVAL' is?

IIRC the point of the nextval() is to ensure that the internal state of
the sequence is correct.  There's a bool "is_called" in the sequence
that means something like "I've been nextval()'d at least once", and the
only clean way to make that become set is to issue a nextval.  You can
watch the behavior by doing "select * from sequenceobject" between
sequence commands --- it looks like the first nextval() simply sets
is_called without changing last_value, and then subsequent nextval()s
increment last_value.  (This peculiar arrangement makes it possible
to have a starting value equal to MININT, should you want to do so.)
So pg_dump needs to make sure it restores the correct setting of both
fields.

This is pretty grotty because it looks like there's no way to clear
is_called again, short of dropping and recreating the sequence.
So unless you want to do that always, a data-only restore couldn't
guarantee to restore the state of a virgin sequence.
        regards, tom lane