mlw wrote:
> Jan Wieck wrote:
> >
> > mlw wrote:
> > > [...]
> > >
> > > IMHO modifying the function manager to allow the return of a full row, and a
> > > "set of" full rows, answers a LOT of issues I have seen over the years with
> > > PostgreSQL extensibility.
> >
> > Sure. Actually I think you'll have an easy project with this
> > one, because all the work has been done by Tom already.
> >
> > The function manager isn't the problem any more. It is that
> > you cannot have such a "set of" function in the rangetable.
> > So you have no mechanism to USE the result.
>
> I'm not sure I follow you. OK, maybe I identified the wrong portion of code.
>
> The idea is that the first return value could return an array of varlenas, one
> for each column, then a set of varlenas, one for each column.
>
> Is there a way to return this to PostgreSQL?
There is a way to return anything. The problem in PostgreSQL is to actually USE it.
Our idea originally was to extend the capabilities of a rangetable entry. Currently, rangetable entries
canonly hold a relation, which is a table or a view. After rewriting, they are down to real tables only.
But basically, a rangetable entry should just be a row- source, so that a function returning a row-set
could occur there too.
In order to avoid multiple calls to the function because of nestloops and the like, I think when a set function
occursin a RTE, it's result should be dumped into a sort-tape and that is used as the row source in the rest of the
plan.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com