Sean:

>Your schema definition probably contains a "serial primary key".
>The "serial" part uses a sequence to do the auto-incremented values, so
postgres needs to create that sequence
>A primary key needs to have an associated index, so by asking for a
primary key, postgres needs to create the index

Thank you very much.

So, if I understand correctly,
the serial primary keys and its index are recreated.

Which means that the value of the primary keys in the restored database
may not be the same
as the value of the primary keys in the original database ?

Kind regards,
Marcel.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On 6/1/06 8:38 AM, "Marcel Franke" <Marcel.Franke@omroep.nl> wrote:

>
> Sean:
>
>> Your schema definition probably contains a "serial primary key".
>> The "serial" part uses a sequence to do the auto-incremented values, so
> postgres needs to create that sequence
>> A primary key needs to have an associated index, so by asking for a
> primary key, postgres needs to create the index
>
> Thank you very much.
>
> So, if I understand correctly,
> the serial primary keys and its index are recreated.
>
> Which means that the value of the primary keys in the restored database
> may not be the same
> as the value of the primary keys in the original database ?

No. The "serial" column only gets an auto-increment value if no value is
specified. For a restore, those values will be present and used. Also, the
sequence (from which any new auto-increment values will be drawn) will be
set to the value from the previous database, so new values will start in the
same place. So, you don't have to put any thought into it--postgres is
doing the right thing here.

Sean


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster