There is a similar discussion going on in the jonas users mailing list..
Your approach below does not appear to be thread safe. There is no
guarantee that the same value will not be selected twice on two concurrent
inserts.. Even more so since it sounds like he is going to be doing the
maxid() and the insert statements separately..
-Erik
At 09:35 AM 6/26/00 -0600, Kyle Bateman wrote:
>
>If one has a unique-id generating sequence that sometimes is bound to
>have holes in it (ie: it could happen that a nextval(seq) happens
>without a corresponding INSERT in the table), then how could one
>efficiently scan for these holes to recycle them in subsequent INSERTs? I'm
>just looking for a "standard" way of doing this if such a thing
>exists. Louis-David Mitterrand - ldm@apartia.org - http://www.apartia.fr
>
> Here's an example: create function maxid () returns int4 as '
> declare
> mv int4;
> begin
> select max(id) into mv from mytab;
> if mv is null then return 0; end if;
> return mv;
> end;
>' language 'plpgsql'; create table mytab (
> id int4 primary key default (maxid() + 1),
> data text
>); insert into mytab (data) values ('Hi there');
>insert into mytab (data) values ('Howdy');
>insert into mytab (data) values ('Guten Tag');
>insert into mytab (data) values ('Terve'); select * from mytab;
>
> BTW hackers, this is a common enough request, I wonder if there should be
>a built-in feature to make it easier for people to put this into the
>default value in the table definition i.e.: create table mytab (
> keycolumn int4 primary key default coalesce(max(keycolumn),0)+1,
> data text
>); Wouldn't this eliminate the need for rollback-able sequences?
> Attachment Converted: "c:\program files\eudora lists\attach\kyle13.vcf"
