Re: [HACKERS] Function-manager redesign: second draft (long)

wieck(at)debis(dot)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