Re: [HACKERS] PL/pgSQL - for discussion

ocie@paracel.com

From: ocie@paracel.com
To: jwieck@debis.com
Cc: pgsql-hackers@postgreSQL.org
Date: 1998-03-12T20:16:13Z
Lists: pgsql-hackers
Jan Wieck wrote:
> 
> Hi,
> 
>     as  I  proposed,  I'm  now  starting on the PL/pgSQL loadable
>     procedural language. As far as I'm now I  have  a  pl_handler
>     with  an  independent  flex/bison  parser  that  can  parse a
>     rudimentary implementation of the language. The next step  is
>     to  start  on the PL/pgSQL executor and look if the generated
>     instruction tree can be used (up to now the  pl_handler  only
>     dumps the instruction tree and returns a 0 Datum.
> 
>     If  that  works  I'll  expand  the scanner/parser to the full
>     PL/plSQL language including trigger procedures.
> 
>     But I would like to have some discussion on language  itself.
>     So  I wrote down what I had in mind. The document is appended
>     below.
> 
>     Please comment/suggest !
> 
>     Someone gave a hint about global variables existing during  a
>     session.   What  is  a  session  than?  One  transaction? The
>     backends lifetime?  And should global variables be visible by
>     more  than one function?  I vote for NO! In that case we need
>     something like packages of functions that share globals.
> 
> 
> Jan

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.

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.

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

Ocie