X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 8A28C9DD717 for ; Fri, 13 Jan 2006 17:28:34 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 91921-08 for ; Fri, 13 Jan 2006 17:28:31 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mailbox.samurai.com (mailbox.samurai.com [205.207.28.82]) by postgresql.org (Postfix) with ESMTP id 004499DD75C for ; Fri, 13 Jan 2006 17:28:27 -0400 (AST) Received: from localhost (mailbox.samurai.com [205.207.28.82]) by mailbox.samurai.com (Postfix) with ESMTP id 9A9A223945B; Fri, 13 Jan 2006 16:28:29 -0500 (EST) Received: from mailbox.samurai.com ([205.207.28.82]) by localhost (mailbox.samurai.com [205.207.28.82]) (amavisd-new, port 10024) with LMTP id 52186-01-4; Fri, 13 Jan 2006 16:28:28 -0500 (EST) Received: from [192.168.1.104] (d38-160-188.home1.cgocable.net [72.38.160.188]) by mailbox.samurai.com (Postfix) with ESMTP id 304B7239457; Fri, 13 Jan 2006 16:28:28 -0500 (EST) Subject: Re: insert without oids From: Neil Conway To: Michael Stone Cc: pgsql-performance@postgresql.org In-Reply-To: <20060113201011.GI1408@mathom.us> References: <20060113201011.GI1408@mathom.us> Content-Type: text/plain Date: Fri, 13 Jan 2006 16:29:15 -0500 Message-Id: <1137187755.2509.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mailbox.samurai.com X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.124 required=5 tests=[AWL=0.124] X-Spam-Score: 0.124 X-Spam-Level: X-Archive-Number: 200601/168 X-Sequence-Number: 16646 On Fri, 2006-01-13 at 15:10 -0500, Michael Stone wrote: > OIDs seem to be on their way out, and most of the time you can get a > more helpful result by using a serial primary key anyway, but I wonder > if there's any extension to INSERT to help identify what unique id a > newly-inserted key will get? Using OIDs the insert would return the OID > of the inserted row, which could be useful if you then want to refer to > that row in a subsequent operation. You could get the same result by > manually retrieving the next number in the sequence and using that value > in the insert, but at the cost of additional DB operations. There's really no additional operations required: INSERT INTO t1 VALUES (...); INSERT INTO t2 VALUES (currval('t1_id_seq'), ...); You need a separate SELECT if you want to use the generated sequence value outside the database, although the INSERT ... RETURNING extension will avoid that (there's a patch implementing this, although it is not yet in CVS). -Neil