Re: procedure returns a tuple

From: wieck(at)debis(dot)com (Jan Wieck)
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: procedure returns a tuple
Date: 2000-04-03 21:07:53
Message-ID: m12cE4f-0003kGC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Karel Zak wrote:

> I a little study on DejaNews a large discussion (October 1999) about new
> fmgr and functions which return tuples. (IMHO 'function' is not good name
> for this, better is 'procedure'.)
>
> A question, is this feature planned for 7.1 and work on this anyone?
>
> IMHO it not needs change current fmgr code, it needs only RTE code (parser
> and transformStmt) and executor code change (executor call myfunc() and this
> function create temp table and this table use executor as standart table.)
> (..it is really simplification :-)
>
> Or is other idea?

Right - simplified.

Here again, the proposed overhaul of the parse-/querytree is
the reason why we don't want to tackle this issue now. At
that time, any relation as well as a 'procedure' (function
returning a tuple set) will become a "tuple-source". A tuple
source is mainly an abstract node, describing the shape of
tuples it returns, hiding how it produces them to the caller.

This way, there is no fundamental difference between a
relation, a procedure or an external database link any more.

Up to now we only have a vague idea in mind. And we're not
sure if we'll do this huge changes in the main CVS trunk or a
separate branch. Neither have we decided when to start on
it, because we need a couple of key developers at the same
time to ensure reasonable progress in that project (none of
us can do it alone).

After 7.0 is out, I'll try to collect all the design issues,
break up the entire package into smaller chunks and develop a
project plan for it.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2000-04-03 21:10:36 Re: Problem with view
Previous Message Bruce Momjian 2000-04-03 20:49:11 Re: BIT datatype (Fixed)