Re: AW: AW: functions returning records

Поиск
Список
Период
Сортировка
От Alex Pilosov
Тема Re: AW: AW: functions returning records
Дата
Msg-id Pine.BSO.4.10.10106270644010.7004-100000@spider.pilosoft.com
обсуждение исходный текст
Ответ на AW: AW: functions returning records  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список 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 по дате отправления:

Предыдущее
От: Alex Pilosov
Дата:
Сообщение: Re: functions returning records
Следующее
От: Alex Pilosov
Дата:
Сообщение: Re: Non-trivial rewriting sql query