Re: [HACKERS] PL/pgSQL - for discussion

Jan and Vadim (I think) discuss:
> >
> > Why PL/pgSQL should be loadable PL? Why not built-in ?
> > Would it be possible to add dirrect support for PL/pgSQL syntax
> > to current parser ?
...
>     Well,  PL/pgSQL  could  be  compiled  in  and  the pl_handler
>     function  and  language  tuples   set   at   bootstrap.   But
>     incorporating  the parser into the backends main parser isn't
>     nesseccary then either. Not that I think it's impossible, but
>     the current main parser is complex enough for me.

I agree, for a language this simple, it would be nice to have it
in the main parser. This might not be too hard since the existing statements
are not really changing, only some new ones are added. eg:

Select_Stmt := SELECT _name_list FROM _from_clause WHERE _where_clause_
...

+ If_Stmt := IF _expression_ THEN _statement_list END
+ Loop_Stmt := ...

Or whatever the grammar looks like.

A bit harder is that the executor now has to sequence through the statements
and handle branches and storing variables etc.

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

Agree.

>     OK.
>
> > >     more  than one function?  I vote for NO! In that case we need
> > >     something like packages of functions that share globals.
> >
> > Let's leave packages for future, but why session-level variables
> > shouldn't be visible inside procedures right now?
>
>     For  security. At least I would like the visibility of global
>     variables depend on the functions owner. So users A and B can
>     use the same global name in their functions but the variables
>     are different.

Not a problem. If the global variables are global only to the session they
can be stored in allocated memory, not in the shared memory. Automatically
then they are private to the user of that session and are destroyed when
the session ends.

> > >             [<<label>>]
> > >             [DECLARE
> > >                 -- declarations]
> > >             BEGIN
> > >                 -- statements
> > >             END;
> >
> > Someday we'll have nested transactions...
> > How about disallow using BEGIN/END as transaction control statements
> > right now ?
> > START/COMMIT/ROLLBACK/ABORT and nothing more...
>
>     Right now!

Hmmm, I like BEGIN TRAN/END TRAN/ABORT TRAN. I suppose there is a standard
we should be following... Also, we probably should not start breaking
existing applications, users get very fussy about that.

> > >             throw messages into the PostgreSQL elog mechanism.
> > >
> > >                 ELOG level 'format' [identifiers];
> >                   ^^^^^^^^^^
> > NO, pls - too postgres-ish! Just let ABORT to have 'format' etc and add
> > PRINT (or something like this) to put some messages to application (via NOTICE).

What is wrong with ELOG? It seems concise and does what is wanted, yes?
Why add syntax?

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - I realize now that irony has no place in business communications.