Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f1O5AAx58606 for ; Sat, 24 Feb 2001 00:10:10 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f1O5A9910821; Sat, 24 Feb 2001 00:10:09 -0500 (EST) To: Jeff MacDonald cc: pgsql-sql@postgresql.org Subject: Re: bug.. ? In-reply-to: References: Comments: In-reply-to Jeff MacDonald message dated "Thu, 22 Feb 2001 15:55:03 -0400" Date: Sat, 24 Feb 2001 00:10:08 -0500 Message-ID: <10818.982991408@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200102/381 X-Sequence-Number: 1582 Jeff MacDonald writes: > A person recent pointed this out to me.. > seems a bit funny, because limit 1 pretty much > say's it't not gonna return multiple values. >> CREATE FUNCTION vuln_port(int4) RETURNS int4 AS 'SELECT port FROM >> i_host_vuln WHERE vuln = $1 GROUP BY port ORDER BY count(port) DESC >> LIMIT 1' LANGUAGE 'sql'; >> >> The result: >> ERROR: function declared to return int4 returns multiple values in final >> retrieve It's a combination of a bug and a poorly worded error message. It is complaining not about rows, but about the extra column needed to do the ORDER BY. The error check forgets to ignore this 'hidden' column. Fixed some time ago for 7.1... regards, tom lane