Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 12B4B9F9379; Thu, 4 Oct 2007 11:48:52 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 75022-05; Thu, 4 Oct 2007 11:48:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-254.commandprompt.net [207.173.203.254]) by postgresql.org (Postfix) with ESMTP id 9B1D59FB312; Thu, 4 Oct 2007 11:48:42 -0300 (ADT) Received: from perhan.alvh.no-ip.org (201-220-98-36.bk9-dsl.surnet.cl [201.220.98.36]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id l94Ekw8W018413; Thu, 4 Oct 2007 07:46:59 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E66A647C6E; Thu, 4 Oct 2007 10:46:56 -0400 (CLT) Date: Thu, 4 Oct 2007 10:46:56 -0400 From: Alvaro Herrera To: Shane Ambler Cc: PostgreSQL Hackers , Stephan Szabo , Jeff Frost , pgsql-sql@postgresql.org Subject: Re: [HACKERS] Why does the sequence skip a number with generate_series? Message-ID: <20071004144656.GK6176@alvh.no-ip.org> References: <20071003175808.P16566@megazone.bigpanda.com> <4704F7CA.4070200@Sheeky.Biz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4704F7CA.4070200@Sheeky.Biz> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Scanned: ClamAV 0.91.1/4466/Wed Oct 3 22:05:43 2007 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Thu, 04 Oct 2007 07:47:04 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/26 X-Sequence-Number: 29398 Shane Ambler wrote: > Stephan Szabo wrote: >> On Tue, 2 Oct 2007, Jeff Frost wrote: >>> I expected these numbers to be in sync, but was suprised to see that the >>> sequence skips a values after every generate series. >>> >>> CREATE TABLE jefftest ( id serial, num int ); >>> INSERT INTO jefftest (num) values (generate_series(1,10)); >>> INSERT INTO jefftest (num) values (generate_series(11,20)); >>> INSERT INTO jefftest (num) values (generate_series(21,30)); >> It seems to do what you'd expect if you do >> INSERT INTO jefftest(num) select a from generate_series(1,10) as foo(a); >> INSERT INTO jefftest(num) select a from generate_series(11,20) as foo(a); >> INSERT INTO jefftest(num) select a from generate_series(21,30) as foo(a); >> I tried a function that raises a notice and called it as >> select f1(1), generate_series(1,10); >> and got 11 notices so it looks like there's some kind of phantom involved. > > That's interesting - might need an answer from the core hackers. > I am posting this to pgsql-hackers to get their comments and feedback. > I wouldn't count it as a bug but it could be regarded as undesirable side > effects. Don't use set-returning functions in "scalar context". If you put them in the FROM clause, as Stephan says above, it works fine. Anywhere else they have strange behavior and they are supported only because of backwards compatibility. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support