Re: PL/PgSQL discussion

Jan Wieck wrote:

> Hannu Krosing wrote:
> >
> > jwieck@debis.com (Jan Wieck) wrote:
> >
> > >     Someone gave a hint about global variables existing during  a
> > >     session.   What  is  a  session  than?  One  transaction? The
> > >     backends lifetime?
> >
> > I think it is a time from connect to disconnect, which currently equals to backends
> > lifetime, but may in future be shorter, if we will implement a backend pool for
> > quick-starting servers.
>
>     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.

> > >
> > >         PL/pgSQL is a block oriented language. A block is defined as
> > >
> > >             [<<label>>]
> > >             [DECLARE
> > >                 -- declarations]
> > >             BEGIN
> > >                 -- statements
> > >             END;
> >
> >
> >
> > >
> > >
> > >         There  can  be  any  number  of  subblocks  in the statements
> > >         section of a block. Subblocks can be used to  hide  variables
> > >         from  outside a block of statements (see Scope and visability
> > >         below).
> >
> > I think that subblock should also be used as the extent of IF, FOR ... LOOP, WHILE and
> > other such statements.
> >
> > 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 ;)

> > >
> > >     Declarations
> > >
> > >         All variables, rows and records  used  in  a  block  or  it's
> > >         subblocks must be declared in the declarations section of the
> > >         block.   The   parameters   given   to   the   function   are
> > >         automatically  declared  with  the usual identifiers $n.
> >
> > How hard would it bet to have named parameters, or why must we use alias?
>
>     That isn't subject to the PL  handler.  All  the  PL  handler
>     knows about the function is in pg_proc and pg_type. There are
>     no parameter names, and that's what the ALIAS idea came from.

I just meant them as an automatic way to declare and use aliases for $N, like for example C
does currently.

The calling function does not know the local names of called function in C either.

>     If we sometimes implement a new function call interface, this
>     might be possible. Some details about what I have in mind:
>
>         Add a field to pg_proc that tells the  backend  the  call
>         interface the function uses.
>
>         Create   a  new  catalog  pg_parameter,  that  holds  the
>         parameter names  and  other  information  (like  notnull,
>         atttypmod etc.). So a function can be defined to expect a
>         VARCHAR(20) NOT NULL.

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.

>     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 ;)

---------

Hannu