Re: [HACKERS] Function-manager redesign: second draft (long) - Mailing list pgsql-hackers

wieck@debis.com (Jan Wieck) writes:
>>>> Also  I miss the interface for tuple set returns. I know that
>>>> this requires much more in other sections than only the fmgr,
>>>> but  we  need  to  cover it now or we'll not be able to do it
>>>> without another change to the fmgr interface at the  time  we
>>>> want  to  support real stored procedures.
>> 
>> OK, I'm willing to worry about that.  But what, exactly, needs to
>> be provided in the fmgr interface?

>     First we need another relation type in pg_class. It's like  a
>     table  or  view, but none of the NORMAL SQL statements can be
>     used with it (e.g.  INSERT, SELECT, ...). It just describes a
>     row structure.

Why bother?  Just create a table --- if you don't want to put any
rows in it, you don't have to.

>     Of  course,  it  requires  some  new fields in the rangetable
>     entry.  Anyway, at the beginning  of  execution  for  such  a
>     query,  the  executor  initializes  those RTE's by creating a
>     temptable with the  schema  of  the  specified  structure  or
>     relation.  Then  it  calls the user function, passing in some
>     handle to the temp table and the user function fills  in  the
>     tuples. Now the rest of query execution is if it is a regular
>     table. After execution, the temp table is dropped.

OK, but this doesn't answer the immediate problem of what needs to
appear in the fmgr interface.

I have been thinking about this some, and I think maybe our best bet is
not to commit to *exactly* what needs to pass through fmgr, but rather
to put in a couple of generic hooks.  I can see two hooks that are
needed: one is for passing "context" information, such as information
about the current trigger event when a function is called from the
trigger manager.  (This'd replace the present CurrentTriggerData global,
which I hope you'll agree shouldn't be a global...)  The other is for
passing and/or returning information about the function result --- maybe
returning a tuple descriptor, maybe passing in the name of a temp table
to put a result set in, maybe other stuff.  So, I am thinking that we
should add two fields like this to the FunctionCallInfo struct:
Node    *resultinfo;   /* pass or return extra info about result */Node    *context;      /* pass info about context of
call*/
 

We would restrict the usage of these fields only to the extent of saying
that they must point to some kind of Node --- that lets callers and
callees check the node tag to make sure that they understand what they
are looking at.  Different node types can be used to handle different
situations.  For an "ordinary" function call expecting a scalar return
value, both fields will be set to NULL.  Other conventions for their use
will be developed as time goes on.

Does this look good to you, or am I off the track entirely?
        regards, tom lane