Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C36766321BE for ; Thu, 22 Oct 2009 12:15:34 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 32332-02 for ; Thu, 22 Oct 2009 15:15:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cirrus.hsolutions.ch (cirrus.hsolutions.ch [212.203.66.103]) by mail.postgresql.org (Postfix) with ESMTP id DA1DF6349EC for ; Thu, 22 Oct 2009 12:15:26 -0300 (ADT) Received: from [192.168.32.120] (unknown [78.234.64.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cirrus.hsolutions.ch (Postfix) with ESMTPSA id 917A7880003; Thu, 22 Oct 2009 17:20:18 +0200 (CEST) Message-ID: <4AE07708.7020506@hsolutions.ch> Date: Thu, 22 Oct 2009 17:15:20 +0200 From: Denis BUCHER Organization: Horus Digital Solutions =?ISO-8859-1?Q?S=E0rl?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Lane CC: pgsql-sql@postgresql.org Subject: Re: Problem with return type of function ??? (corrected) References: <4AE046E4.8010205@hsolutions.ch> <29935.1256222015@sss.pgh.pa.us> In-Reply-To: <29935.1256222015@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200910/108 X-Sequence-Number: 33307 Hi Tom, Another question : Tom Lane a écrit : > Denis BUCHER writes: >> I have a strange problem, because it worked in a fonction for a table, >> and now I created the same (?) function for another table and it doesn't >> work... > >> The function is accepted but at runtime I get : > >> ERREUR: wrong record type supplied in RETURN NEXT >> CONTEXTE : PL/pgSQL function "find_sn_live" line 26 at return next > > Does that table have any dropped columns? If you don't remember > whether you ever dropped any columns, a quick look into pg_attribute > will tell you: > select attname from pg_attribute where attrelid = 'rma.serial_number'::regclass; > > plpgsql isn't tremendously good with rowtypes that contain dropped > columns. I believe this particular case is fixed in CVS HEAD, but the > patch was a bit invasive and won't get back-ported to existing releases. > The workaround is to drop and recreate the table without any dropped > columns. To do this it will be a little complicated because of table dependencies... And it could bug again at the next DROP COLUMN... Is there a way to change my function (RETURN SETOF part) to specify the column names/types ? Thanks a lot again Denis