Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9C8DB632A88 for ; Thu, 22 Oct 2009 11:39:08 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 66310-04 for ; Thu, 22 Oct 2009 14:38:48 +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 612156321BE for ; Thu, 22 Oct 2009 11:38:56 -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 55BD0880003; Thu, 22 Oct 2009 16:43:47 +0200 (CEST) Message-ID: <4AE06E75.9010305@hsolutions.ch> Date: Thu, 22 Oct 2009 16:38:45 +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.531 tagged_above=-10 required=5 tests=AWL=0.068, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200910/105 X-Sequence-Number: 33304 Hello Tom, 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; Yes ! attname ------------------------------ tableoid cmax xmax cmin xmin ctid sn_id sn no_client no_art_bw sn_fc_date ........pg.dropped.6........ ........pg.dropped.7........ desc_fr sn_cm_date no_facture no_commande (17 lignes) > 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. OH, I see... Thanks a lot, I will try this later today when nobody uses the application... Denis