Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hVdZq-0000wz-IE for pgsql-general@arkaria.postgresql.org; Tue, 28 May 2019 14:59:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hVdZn-0004uL-M0 for pgsql-general@arkaria.postgresql.org; Tue, 28 May 2019 14:59:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hVdZl-0004u6-V3; Tue, 28 May 2019 14:59:43 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hVdZe-0005Yz-Dy; Tue, 28 May 2019 14:59:40 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ECB21223E8; Tue, 28 May 2019 10:59:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 28 May 2019 10:59:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=s 4FK/Y1nCVGcz9hRN4P0DBpX48ZX+OpxpcTsBMk6olw=; b=oIiayOM6BcNqkiXn1 SfUaamitr8CacXkaWwhvY7ANDoLFVuLxHor7fjQsziNVX0ouLSlutW0IcB3GJATx FLtfqMjUw/ogrVNfQCT384CqzP7YHMe42u0RXjtb+AqEtzjjfU9VqdI7anCU8Lx0 VP3w/VA7ePmWGZL1YrCqS1aF1jrukBr9ZSSQ58e6yyWKoDactqQMOhtDnY4aYMD+ 5+I94uXsVDg8qf90vwj10maY8OIYwX3Z/siNCzJVjiVqEP1GzhqqYL1gBBlJSuR9 FOWQdj6clfa6v6TgvpdEIWbFb8XCoxQmAOT4vcTKr2HIOp3Z6tWjk5n/guBY77XY PawGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=s4FK/Y1nCVGcz9hRN4P0DBpX48ZX+OpxpcTsBMk6o lw=; b=GsccYiRFeRhl15/OmFsCe6Nmzk7k3qUrHw6yoaMFy1EAKQefj1VTD6dE+ /jy1pQ9xWMwMBzgYpTjaSVxbQ2mCPDOZ5wdA9JziuJ6q72Sjj6iHUh3FPUSKG/Jl pAcU+WObJLgi3/shGjEQ7e38lDEFRItjaMrLzkj+rG5tHwf4LJ7THbQIfrL/o+Qa P7jTMTdIHZUtSlK+3bJk3YLACN7v7Ds7WC0Xe0POqwDXrjJWcmfMK0MAq364Qi3H 8TrJzl2tySlLpyBSvBThvnYuFxwWLutu57Ux7HG5Dkw2HZ6Xn8KNQYL7+zIlxiNh Y4mOelNHRsq/F8qmkb7iRW1BSI7Xg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvhedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheptegurhhi rghnucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtoh hmqeenucffohhmrghinhepsgdrihgupdhpohhsthhgrhgvshhqlhdrohhrghdprgdrihgu necukfhppeejuddrvdduvddrudehtddrvddtvdenucfrrghrrghmpehmrghilhhfrhhomh eprggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: from [192.168.1.4] (unknown [71.212.150.202]) by mail.messagingengine.com (Postfix) with ESMTPA id AC6418005C; Tue, 28 May 2019 10:59:31 -0400 (EDT) Subject: Re: Alternate methods for multiple rows input/output to a function. To: RAJIN RAJ K , pgsql-sql@postgresql.org, pgsql-hackers@postgresql.org, pgsql-general@postgresql.org References: From: Adrian Klaver Message-ID: Date: Tue, 28 May 2019 07:59:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 5/28/19 7:36 AM, RAJIN RAJ K wrote: > --> Function ' filter_id ' filters the ID's based on some conditions. > --> Input is set of ID's. (Not directly taking the input since there is > no provision to pass multiple rows to a function) To be honest I cannot follow what you are trying to achieve below. I do have one suggestion as to creating temp tables. Why not use a CTE: https://www.postgresql.org/docs/11/queries-with.html in the function to build a 'temp' table on the fly? > > create function filter_id() > return table (id bigint) > begin > > --> Assuming input table is already created #temp_input_id > > retun query as select id > from tbl a > inner join > #temp_input_id b on (a.id = b.id ) > where a.; > > end; > > > --> Calling Function: > > create function caller() > return table (id bigint,col1 bigint, col2 bigint) > begin > > --> do some processing > > --> Find out the input id's for filtering. > > --> Create temp table for providing input for the filtering function > > create temp table #TEMP1 > as select id from tbla........; > (Cannot move the input id logic to  filter_function) > > --> calling the filter function > create temp table #TEMP2 > as select * from filter_id(); --> This is a generic function used in > many functions. > > > return query > as select a.* > from tb3 a inner join tb4 inner join tb 5 inner join #TEMP2; > end; > > > Is there any alternate way of achieving this? Passing multiple records > to a function im creating a temp table before invoking the function. > For receiving an output of multiple rows i'm creating a temp table to > reuse further in the code. > > Can this be done using Refcursor? Is it possible to convert refcursor to > a temp table and use it as normal  table in query? > > -- Adrian Klaver adrian.klaver@aklaver.com