Thread: Inserting values into a SERIAL field

Hi all,

Is there any SQL statement to PostgreSQL that will allow me to insert rows
with a specified value for the SERIAL value. I know this is not what you
want to do normally, but I'm trying to provide a kind of general export and
import function to a generic database. Since there exists foreign key values
in instances of other tables that point into field values for a table that
has a SERIAL id, I'd like to somehow import all this data and continue using
the SERIAL functionality for the highest value of the id fields.

Ian

On Sun, Mar 04, 2001 at 05:22:46PM +0000, some SMTP stream spewed forth:
> Hi all,
>
> Is there any SQL statement to PostgreSQL that will allow me to insert rows
> with a specified value for the SERIAL value. I know this is not what you
> want to do normally, but I'm trying to provide a kind of general export and
> import function to a generic database. Since there exists foreign key values
> in instances of other tables that point into field values for a table that
> has a SERIAL id, I'd like to somehow import all this data and continue using
> the SERIAL functionality for the highest value of the id fields.

I think what you want is
insert into table (<serial_col>, <whatever>,...) values (...);


dan

>
> Ian
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

Greetings.

I just received the following error attempting to do a vacuum on my
database:

freehost=# vacuum analyze;
NOTICE:  Rel pg_language: TID 0/1: OID IS INVALID. TUPGONE 1.
ERROR:  Index pg_language_oid_index is not a btree

And I see several errors in the logs regarding invalid function calls.  When
I attempt to call any user-defined function I receive :

freehost=# select add_pageview( 1 );
ERROR:  Index pg_language_oid_index is not a btree

The only oddity during this time was the postgres process handling the
vacuum shot up to 685MB worth of RAM usage (638 shared) during the vacuum.

This is a Debian 2.2 system running PostgreSQL 7.0.3...

Help? :)

Sincerely, Warren