Jan Wieck wrote:
> > > Hmmm - how does a language handler then notice that a new
> > > session began?
> >
> > Probably by defining the reset_session or init_session functions for the language handler and
> > calling it at the connect time.
>
> Not in the current implementation of the backend/pl_handler
> interface. But a global variable SessionId might help.
Neither do we have backend pooling now.
> > > > Then we would not need the END IF, END LOOP etc.
> > >
> > > The LOOP ... END LOOP etc. syntax is just what I saw in
> > > Oracles PL/SQL documentation. I could also live with
> > > BEGIN...END, but what is it good for to be different?
> >
> > then again we don't need the block delimiters ;)
>
> Forgotten in the 1st draft. Variables are initialized to
> their default values every time a block/subblock is entered.
> Not only when the function is entered.
>
> ...
> FOR i IN 1..10 LOOP
> DECLARE
> flag bool DEFAULT false;
> n integer DEFAULT 0;
> BEGIN
> ...
> END;
> END LOOP;
> ...
Ok, this makes sense.
> > This again can be done by automatically rewriting these to additional statements to check for
> > this as first things in the function body. It makes only a theoretical difference if the error
> > is reportid before the call or just after it.
>
> But this rewriting must be done when the function is created.
> At this time, the pl_handler and it's parser aren't called.
Ok, I understand it now.
<name> ALIAS FOR $n;
is to overcome the split between the two parser.
> It is done by the backends main parser. For loadable
> procedural languages, the main parser doesn't know anything
> about the languages syntax or if the string given after AS is
> a program text at all. It only creates the pg_proc tuple.
And another thing:
Does'nt the Oracle PL/SQL have both input and input/output parameters ?
It's more than a year since i last used it but I think that this is the case.
Hannu