Re: AW: AW: functions returning records - Mailing list pgsql-hackers

From Alex Pilosov
Subject Re: AW: AW: functions returning records
Date
Msg-id Pine.BSO.4.10.10106270644010.7004-100000@spider.pilosoft.com
Whole thread Raw
In response to AW: AW: functions returning records  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
On Wed, 27 Jun 2001, Zeugswetter Andreas SB wrote:

> 
> > >>  For the result from foo() you must somewhere define attributes (names). 
> > >> Where? In CREATE FUNCTION statement? Possible must be:
> > >> 
> > >>  select name1, name2 from foo() where name1 > 10;
> > > 
> > > Yes, optimal would imho also be if the foo() somehow had access to the
> > > where restriction, so it could only produce output, that the
> > > higher level is interested in, very cool. This would be extremely 
> > > useful for me. Very hard to implement, or even find an appropriate 
> > > interface for though.
> > 
> > You could easily implement it *in* the function foo IMHO. Since the 
> > function does some black magic to create the result set to begin with, you 
> > can change it to use parameters:
> > 
> > select name1, name2 from foo(10, NULL, NULL) where name1 > 10;
> 
> Yes, but this is only an answer to a limited scope of the problem at hand,
> and the user who types the select (or uses a warehouse tool) needs substantial 
> additional knowledge on how to efficiently construct such a query.
> 
> In my setup the function would be hidden by a view.
Its a different problem. Functions returning tables do just that, return
tables, they won't care just what from that table you need. Exposing
pieces of optimizer to your function doesn't seem to me like a great
idea...



pgsql-hackers by date:

Previous
From: Alex Pilosov
Date:
Subject: Re: functions returning records
Next
From: Alex Pilosov
Date:
Subject: Re: Non-trivial rewriting sql query