X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.192]) by svr1.postgresql.org (Postfix) with ESMTP id 13B8ECC3E0 for ; Tue, 15 Jul 2003 14:55:30 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr4.postgresql.org [64.117.224.192]) (amavisd-new, port 10024) with ESMTP id 10711-02 for ; Tue, 15 Jul 2003 14:55:48 +0000 (GMT) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by svr1.postgresql.org (Postfix) with ESMTP id C5ECFCC3D7 for ; Tue, 15 Jul 2003 11:55:23 -0300 (ADT) Received: from stark.dyndns.tv (H162.C233.tor.velocet.net [216.138.233.162]) by sabre.velocet.net (Postfix) with ESMTP id 7B93513914C; Tue, 15 Jul 2003 10:55:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 19cRDP-0004ut-00; Tue, 15 Jul 2003 10:55:39 -0400 To: "Viorel Dragomir" Cc: Subject: Re: summing tables References: <20030715140921.7c5a6a6c.erik@thiele-hydraulik.de> <001501c34aca$e70ca280$0600a8c0@fix.ro> <20030715143925.54716ed4.erik@thiele-hydraulik.de> <007101c34ad6$3e0249e0$0600a8c0@fix.ro> In-Reply-To: <007101c34ad6$3e0249e0$0600a8c0@fix.ro> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 15 Jul 2003 10:55:38 -0400 Message-ID: <878yqzn8k5.fsf@stark.dyndns.tv> Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200307/176 X-Sequence-Number: 14290 To solve this problem efficiently you probably need the lead/lag analytic functions. Unfortunately Postgres doesn't have them. You could do it with something like: update foo set c = a+b+(select c from foo as x where seq < foo.seq ORDER BY seq desc LIMIT 1) or the more standard but likely to be way slower: update foo set c = a+b+(select c from foo as x where seq = (select max(seq) from foo as y where seq < foo.seq)) However, i would suggest that if you have an implicit relationship between records you should make that relationship explicit with a foreign key. If you had a column that contained the seq of the parent record then this would be easy. I'm really puzzled how this query as currently specified could be useful. -- greg