Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id EAA65476347 for ; Wed, 14 Aug 2002 11:20:07 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 3D8014762EE for ; Wed, 14 Aug 2002 11:20:07 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g7EFK9Vk008506; Wed, 14 Aug 2002 11:20:09 -0400 (EDT) To: Richard Huxton Cc: Andreas Tille , PostgreSQL SQL Subject: Re: Explicite typecasting of functions In-reply-to: <200208141210.29995.dev@archonet.com> References: <200208141210.29995.dev@archonet.com> Comments: In-reply-to Richard Huxton message dated "Wed, 14 Aug 2002 12:10:29 +0100" Date: Wed, 14 Aug 2002 11:20:09 -0400 Message-ID: <8505.1029338409@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200208/234 X-Sequence-Number: 9080 Richard Huxton writes: > On Wednesday 14 Aug 2002 10:30 am, Andreas Tille wrote: >> Any hint to solve this kind of chicken-egg-problem? > Your solution is not safe anyway - you could end up with two processes trying > to insert the next value. I concur with Richard that Andreas needs to solve a different problem, but just for the record, the way you could do it is CREATE TABLE without mentioning the default CREATE FUNCTION ALTER TABLE ... SET DEFAULT Note however that pg_dump is not bright enough to deduce that you did this. It will dump the table definition first, with the DEFAULT clause, and so you'll have to do manual surgery on the dump file if you ever need to reload. regards, tom lane