Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 794DE6322C7 for ; Fri, 3 Apr 2009 12:29: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 47745-02 for ; Fri, 3 Apr 2009 12:29:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp1.islandnet.com (smtp1.islandnet.com [199.175.106.100]) by mail.postgresql.org (Postfix) with ESMTP id 7472F632219 for ; Fri, 3 Apr 2009 12:29:06 -0300 (ADT) Received: from [199.175.106.52] (port=41688 helo=cluster.islandnet.com) by smtpout.islandnet.com with ESMTP id 1LplKK-00084e-6n ; Fri, 03 Apr 2009 08:29:04 -0700 Received: from [24.108.1.50] (port=3341 helo=[192.168.0.193]) by cluster03.islandnet.com with ESMTPSA (TLSv1:AES256-SHA:256) id 1LplKK-0003LY-A4 ; Fri, 03 Apr 2009 08:29:04 -0700 Message-ID: <49D62B3F.9030007@borstad.com> Date: Fri, 03 Apr 2009 08:29:03 -0700 From: Peter Willis Reply-To: peterw@borstad.com User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Adrian Klaver CC: pgsql-sql@postgresql.org Subject: Re: FUNCTION problem References: <1521645855.2691471238710811603.JavaMail.root@sz0030a.emeryville.ca.mail.comcast.net> <200904021816.44804.aklaver@comcast.net> <200904030651.05480.aklaver@comcast.net> <200904030712.38321.aklaver@comcast.net> In-Reply-To: <200904030712.38321.aklaver@comcast.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200904/33 X-Sequence-Number: 32379 Adrian Klaver wrote: > On Friday 03 April 2009 6:51:05 am Adrian Klaver wrote: >> On Thursday 02 April 2009 6:16:44 pm Adrian Klaver wrote: >>> Now I remember. Its something that trips me up, the RECORD in RETURN >>> setof RECORD is not the same thing as the RECORD in DECLARE RECORD. See >>> below for a better explanation- >>> http://www.postgresql.org/docs/8.3/interactive/plpgsql-declarations.html# >>> PL PGSQL-DECLARATION-RECORDS Note that RECORD is not a true data type, >>> only a placeholder. One should also realize that when a PL/pgSQL function >>> is declared to return type record, this is not quite the same concept as >>> a record variable, even though such a function might use a record >>> variable to hold its result. In both cases the actual row structure is >>> unknown when the function is written, but for a function returning record >>> the actual structure is determined when the calling query is parsed, >>> whereas a record variable can change its row structure on-the-fly. >>> >>> >>> >>> -- >>> Adrian Klaver >>> aklaver@comcast.net >> For this particular case the following works. >> >> CREATE OR REPLACE FUNCTION test_function(integer) RETURNS record >> AS $Body$ >> DECLARE croid integer; >> DECLARE R RECORD; >> BEGIN >> SELECT INTO croid 2; >> SELECT INTO R croid,$1; >> RETURN R; >> END; >> >> $Body$ >> LANGUAGE plpgsql; >> >> -- >> Adrian Klaver >> aklaver@comcast.net > > Forgot to show how to call it. > > test=# SELECT * from test_function(1) as test(c1 int,c2 int); > c1 | c2 > ----+---- > 2 | 1 > (1 row) > > Ah!, I see what you mean about the definition of 'RECORD'. (The lights come on...) And here I thought it would all be so simple..... You show a valid, and most informative solution. This should get things working for me. Thank you very much for your help. Peter