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