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

Tom Lane wrote:

> Bruce Momjian <maillist@candle.pha.pa.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@debis.com (Jan Wieck) #