Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: Bill Moran <wmoran@potentialtech.com>
Subject: Re: [PERFORM] Set-Returning Functions WAS: On the performance of
 views
Date: Thu, 29 Jan 2004 15:17:19 -0800
User-Agent: KMail/1.4.3
Cc: pgsql-sql@postgresql.org
References: <40152FF2.8000007@potentialtech.com>
	<200401291121.54048.josh@agliodbs.com>
	<4019629C.3040307@potentialtech.com>
In-Reply-To: <4019629C.3040307@potentialtech.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200401291517.19647.josh@agliodbs.com>

Bill,

> I don't understand at all.  If I do "SELECT * FROM
> set_returning_function()" and all I'm going to do is iterate through the
> columns and rows, adding them to a two dimensional array that will be
> marshalled as a SOAP message, what about not knowing the nature of the
> return set can cause me to get no data?

Because that's not the syntax for a function that returns SETOF RECORD.

The syntax is:

SELECT * 
FROM set_returning_function(var1, var2) AS alias (col1 TYPE, col2 TYPE);

That is, if the function definition does not contain a clear row structure, 
the query has to contain one.

This does not apply to functions that are based on a table or composite type:

CREATE FUNCTION  .... RETURNS SETOF table1 ...
CREATE FUNCTION .... RETURNS SETOF comp_type

Can be called with: 

SELECT * FROM some_function(var1, var2) as alias;

What this means is that you have to know the structure of the result set, 
either at function creation time or at function execution time.

>
> One of the things I love about working with open source databases is I
> don't see a lot of that.  The people on these lists are almost always
> smarter than me, and I find that comforting ;)

Flattery will get you everywhere.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco