Re: PL/PgSQL discussion

Jan Wieck wrote:

> Hannu Krosing wrote:
> >
> > jwieck(at)debis(dot)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