Skip site navigation (1) Skip section navigation (2)

Re: AW: [HACKERS] Re: PL/PgSQL discussion

From: jwieck(at)debis(dot)com (Jan Wieck)
To: andreas(dot)zeugswetter(at)telecom(dot)at (Zeugswetter Andreas)
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: AW: [HACKERS] Re: PL/PgSQL discussion
Date: 1998-03-19 17:10:46
Message-ID: m0yFiq6-000BFRC@orion.SAPserv.Hamburg.dsh.de (view raw or flat)
Thread:
Lists: pgsql-hackers
Andreas Zeugswetter wrote:
>
> >From my experience, it *** is *** impossible. I would be glad if somebody
> told me different, but to my understanding the doc is wrong here.
>
> Andreas
>
> >>     Currently  only  'null'  and  'single  value'.  The  executor
> >>     doesn't  accept anything else for non-sql language functions.
> >>     PL functions are treated by the executor like 'C'  functions.
> >
> >Actually what I understood from the docs was thatit is 'terribly complicated' and 'beyond the
> >scope of this tutorial', but not impossible ;)

    I  have  been thinking about that quite a time and when David
    Gould  said  'looks  like  PL  functions  want  to  _be_  SQL
    functions',  my  first  action was scratching my head. Then I
    thought it would blow up the parser and executor with  things
    they wheren't designed for and dropped these thoughts.

    Anyway  -  thanks  David  -  it  was  a  push  into the right
    direction.  Not that I think PL functions should become  real
    SQL  functions  processed  by  the  backends  main parser and
    executor. But they might become  something  between  'C'  and
    'SQL'.

    The executor could check in ExecMakeFunctionResult() that the
    function  is  a   PL   function   (simply   by   looking   at
    fcache->func.fn_plhandler).   So  it  is  possible  that  the
    Executor    treats     PL     functions     somewhat     like
    postquel_function().

    My  PL/pgSQL is now at the state, that I can write functions.
    I'll leave triggers for later and take a look if that all  is
    possible.   Would be really nice to enable tuples and sets of
    tuples as PL return types and finally beeing able to do a

      DECLARE ret    EMP%ROWTYPE;
      BEGIN
        ...
        FOR ret IN SELECT ... LOOP
          RETURN ret AND RESUME;
        ENDLOOP;
        ...
      END;

    from PL/pgSQL. Well, returning and resume later  might  cause
    some trouble with SPI, but let's see.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #



In response to

Responses

pgsql-hackers by date

Next:From: Massimo Dal ZottoDate: 1998-03-19 17:25:04
Subject: Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Previous:From: The Hermit HackerDate: 1998-03-19 17:05:47
Subject: Re: [HACKERS] tables >2GB

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group