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

Tom Lane wrote:

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Sounds good. My only question is whether people need backward
> > compatibility, and whether we can remove the compatiblity part of the
> > interface and small overhead after 7.1 or later?
>
> I think we could drop it after a decent interval, but I don't see any
> reason to be in a hurry. I do think that we'll get complaints if 7.0
> doesn't have any backward compatibility for existing user functions.

Right. A major release is what it is. And porting
applications to a new major release too, it is a conversion,
not an upgrade. Therefore a major release should drop as much
backward compatibility code for minor releases as possible.

Thus, we should think about getting rid of the broken design
for functions returning tuple sets in 7.0. As far as I
understand the books I have, there are a couple of different
types of functions/procedures out, and not every database
implements all types, nor do they all name one and the same
type equally so that something called function in one
database is a stored procedure in another. Anyway, the
different types are:

1. Functions returning a scalar value taking only input-
arguments.

2. Functions returning a scalar value taking input-, output-
and in/out-arguments.

3. Functions returning nothing taking only input-arguments.

4. Functions returning nothing taking input-, output- and
in/out-arguments.

5. Functions returning a set of result rows taking only
input-arguments.

6. Functions returning a set of result rows taking input-,
output- and in/out-arguments.

I don't think that we have to implement everything, and since
we don't have host variables, output- and in/out-arguments
would make sense only for calls from procedural languages.
OTOH they would cause much trouble so they are one detail to
let out for PostgreSQL.

Three cases left. Type number 1. we have already. And it is
advanced, because the arguments can be either single values,
or single rows.

And type number 3. is easy, because invoking something that
returns a dummy that is thrown away is absolutely no work.

So the only thing that's really left is number 5. The funny
detail is, that those functions or procedures can't be used
inside regular SELECT queries. Instead a CALL FUNCTION or
EXECUTE PROCEDURE statement is used from the client
application or inside a PL block. CALL FUNCTION then returns
a tuple set as a SELECT does. The result in our world
therefore has a tuple descriptor and depending on the invoker
is sent to the client or stored in an SPI tuple table.

So we do not need to call functions returning sets through
the normal function manager. It could competely deny calls to
set functions, and the interface for them can be a total
different one. I have something in mind that could work
without temp tables, but it requires a redesign for PL/pgSQL
and causes some limitations for PL/Tcl. Let's leave that for
a past 7.0 release.

I correct my previous statements and vote to deny calls to
set functions through the default function manager in 7.0.

And there is another detail I found while browsing through
the books. Functions can be defined as [NOT] NULL CALL (IBM
DB2). Functions defined as NOT NULL CALL will be called only
if all their arguments aren't NULL. So we can prevent much
NULL handling inside the functions if we simply define that a
function that is NOT NULL CALL will allways return NULL if
any of it's input arguments is NULL. This case can then be
handled at the function manager level without calling the
function itself. Nearly all our builtin functions behave that
way but have all the tests inside.

Another detail I'm missing now is a new, really defined
interface for type input/output functions. The fact that they
are defined taking one opaque (yepp, should be something
different as already discussed) argument but in fact get more
information from the attribute is ugly.

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