Re: Primary Key with serial the solution? - Mailing list pgsql-general

From Craig Ringer
Subject Re: Primary Key with serial the solution?
Date
Msg-id 47F2F997.30105@postnewspapers.com.au
Whole thread Raw
In response to Re: Primary Key with serial the solution?  ("x asasaxax" <xanaruto@gmail.com>)
List pgsql-general
x asasaxax wrote:
> How about if i do this inside a procedure:
>
> SELECT setval('sequence',(SELECT max(id) FROM table)) INTO variable;
> insert into table values(variable, ..., ...);  ?
>
> Will this be transactional? Cause, they say that setval is a command
> that its transactional. Using this way i
> don´t will need to use a sequence anymore. Is that correct?

If somebody else INSERTs a record between your first and second
statements, it will get the first free value in the sequence so your
INSERT will fail with a unique check voliation. Assuming there's a
unique constraint involved, which I assume there is given your use of a
sequence.

Why do you want to do this? Sequences are designed so that you can just:

INSERT INTO table VALUES ( nextval('sequence'), ..., ...)

or set the DEFAULT on the generated value field such that it calls
nextval('sequence') if the user just does:

INSERT INTO table VALUES ( DEFAULT, ... , ... )

or uses a named-field INSERT and omits the sequence column entirely.

Why not use them that way?

Is there something you're trying to achieve that sequences aren't doing
the job for - like, say, "gap-less" generated values? If that's the
problem please search the archives as it's already been discussed to
death even in the short time I've been a list member.

--
Craig Ringer


pgsql-general by date:

Previous
From: "Douglas McNaught"
Date:
Subject: Re: dblink ,dblink_exec not participating in a Transaction??
Next
From: Craig Ringer
Date:
Subject: Re: Primary Key with auto increment field