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

>
> [ responding to both of Jan's messages in one ]
>
> wieck(at)debis(dot)com (Jan Wieck) writes:
> > I like the current interface for it's simpleness from the user
> > function developers point of view.
>
> There is that; even with a good set of convenience macros there will be
> more to learn about writing user functions. OTOH, the way it is now
> is not exactly transparent --- in particular, NULL handling is so easy
> to forget about/get wrong. We can make that much easier. We can also
> simplify the interface noticeably for standard types like float4/float8.
>
> BTW: I am not in nearly as big a hurry as Bruce is to rip out support
> for the current user-function interface. I want to get rid of old-style
> builtin functions before 7.0 because of the portability issue (see
> below). But if a particular user is using old-style user functions
> and isn't having portability problems on his machine, there's no need
> to force him to convert, it seems to me.

Personally, I could live with dropping the entire old
interface. That's not the problem. But at least Bruce and his
book need to know the final programming conventions if we
ought to change it at all, so it can be covered in his
manuscript when it is sent down to the paper.

> I was going to let the prolang column tell that, by having different
> language codes for old vs. new builtin function and old vs. new
> dynamic-linked C function. We could add a version column instead,
> but that seems like unnecessary complication.

Right - language is all needed to tell.

> > This approach nearly matches all my thoughts about the
> > redesign of the fmgr. In the system table section I miss
> > named arguments.
>
> As you said in your earlier message, that is a parser-level feature
> that has nothing to do with what happens at the fmgr level. I don't
> want to worry about it for this revision.

Right too. I just hoped to expand the scope of this change so
there would only ONE change to the PL handlers covering both,
new interface with proper NULL handling and enhanced function
prototypes.

>
> > 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.

Then, a function returning a SET of any row type (this time,
regular relations or views too) can be used in the rangetable
as

SELECT A.col1, B.col2 FROM mysetfunc() A, anothertab B
WHERE A.col1 = B.col1;

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.

Isn't that all required for true stored procedures?

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) #