Re: [SQL] How to handle a requirement for nextval

From: The Web Administrator <wwwadmin(at)wizard(dot)ca>
To: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
Cc: PGsql <pgsql-sql(at)postgreSQL(dot)org>, maillist(at)candle(dot)pha(dot)pa(dot)us
Subject: Re: [SQL] How to handle a requirement for nextval
Date: 1998-05-19 13:22:39
Message-ID: 3561879F.BE00E0B4@wizard.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Ok, first of all you have given me the EXACT answer I was looking for. But
trust me, I poured over the docs, and there was no ref to a man page on
'create_sequence', otherwise I would have jumped all over it.. (I am using 6.2,
that might be the problem :>) Yes, I saw the OID thing, but that didn't seem
too standard SQL. The biggest problem I see in PostGres is the wide mixture of
docs. Maybe all the examples and readme's should be put together in a more
common package. Possibly a doc package?

Herouth Maoz wrote:

> At 23:33 +0300 on 18/5/98, The Web Administrator wrote:
>
> > What I want is that the Primary Key (Only Key) be type_id, and int, and
> > the first item that I insert should have type_id as '1', next will be
> > '2' etc..
> > I could have every insert into this table include a type_id, but that
> > seems unessary.
> > Can I have something like default='nextval' ?
>
> In order to create an auto-incrementing field - one which will
> automatically receive the value 1 for the first row inserted, 2 for the
> second, and so on - you have to define a sequence. For example:
>
> CREATE SEQUENCE emp_no;
>
> Then you define your table. Assuming you want an employee table in which
> the emp_id field is autoincrementing, here is what you write:
>
> CREATE TABLE emp
> (
> emp_id int4
> DEFAULT nextval( 'emp_no' )
> NOT NULL
> -- Other fields here
> );
>
>

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Anton Stckl 1998-05-19 14:05:25 Re: [SQL] Case in-sensitive searches
Previous Message Jose' Soares Da Silva 1998-05-19 12:31:42 Re: [SQL] Case in-sensitive searches