Re: [HACKERS] PL/pgSQL - for discussion

Ocie wrote:
>
> This looks good.
>
> I especially like the "for x in select ..." part, it looks a lot more
> elegant than cursors, but we might want to provide a cursor with a
> "get next row" and "get previous row" function, as the for loop only
> goes one way.

    We  don't  have  real  cursors  up to now. The SPI_exec() and
    SPI_execp() functions  return  the  complete  set  of  tuples
    selected.   And  I'm not sure if that what PostgreSQL calls a
    cursor can be used in the backend over SPI. It requires named
    portals  and  them in turn require a transaction block (BEGIN
    ... COMMIT).  But I think it would be easy to build something
    that looks like cursors on top of the complete set of tuples.

>
> Another suggestion related to parameters:
>
> >             <name> ALIAS FOR $n;
> >
> >                 For better readability of the code it's  possible  to
> >                 define  an  alias  for  a positional parameter to the
> >                 function.
> >
>
> What is the defined behavior if the user leaves out this parameter?
> Do we generate a runtime error?  If I might suggest the following:
>
> <name> ALIAS FOR $n;
> sets up name as an alias for $n, name is null if that parameter was
> not given.

    The backends main parser chooses functions not only by  name.
    The  number  and  datatypes of the given parameters must also
    match  (function  overloading  -   possible   with   our   PL
    implementation).  If  a  query execution reaches the function
    call, be sure that all parameters are given.

    I thought about it just as  a  way  to  make  the  code  more
    readable.  The parameters might also be accessed by the usual
    $n notation.  So if you have

        empname ALIAS FOR $n;

    in the declarations, empname and $n are identical. Thats  how
    I understand the word ALIAS.

>
> <name> REQUIRED ALIAS FOR $n;
> sets up name as an alias for $n, generate a runtime error if that
> parameter was not given.
>
> Actually, an assignment might be a better way to do this.  I.E. Define
> foo as int not null, assign $2 to foo and if there is an error, the user is notified.

    Does  make  sense.  But for sake a function cannot identify a
    null value in one of the parameters.  The  passed  in  isNull
    flag  only says that one of all parameters is null. Not which
    one. We have to change this someday, and I have already  some
    ideas on that. But that's another topic.


Jan

--

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