Thread

1. procedure returns a tuple

   Karel Zak <zakkr@zf.jcu.cz> — 2000-03-31T15:33:29Z

    Hi,
   
   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?
   
   							Karel
   
   /* ----------------
    * Karel Zak  *  zakkr@zf.jcu.cz  *  http://home.zf.jcu.cz/~zakkr/
    *           C, PostgreSQL, PHP, WWW, http://docs.linux.cz
    * ----------------
    */
   
   
   

2. Re: procedure returns a tuple

   Jan Wieck <wieck@debis.com> — 2000-04-03T21:07:53Z

   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@debis.com (Jan Wieck) #
   
   
   
   

3. Re: procedure returns a tuple

   Karel Zak <zakkr@zf.jcu.cz> — 2000-04-04T12:27:16Z

   On Mon, 3 Apr 2000, Jan Wieck wrote:
   
   > 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'.)
   
   Jan, thanks for answer, I thought that I again ask about bad matter or 
   I send a stupid question :-) 
   
   >     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.
   
   Last weekend I a little explore current sources for this and the
   current postgresql very "vegetates" on a relation and a example 
   transform statement code very depend on relation structs. Yes,
   Berkeley's code design for this is not modular and abstract. 	
   
   >     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.
   
   Well.  
   
   						Karel