Re: [HACKERS] PL/pgSQL - for discussion - Mailing list pgsql-hackers

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.

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 ?
Typing procedure body inside ' is not nice thing, imho.

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

>     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?

>
>         PL/pgSQL is a block oriented language. A block is defined as
>
>             [<<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...

>             <name> <class>%ROWTYPE;
>
>                 Declares a row with the structure of the given class.
>                 Class must be an existing table- or viewname  of  the
>                 database.  The  fields of the row are accessed in the
>                 dot notation. Parameters  to  a  procedure  could  be
>                 tuple   types.   In   that   case  the  corresponding
>                 identifier $n  will  be  a  rowtype.  Only  the  user
>                 attributes  and  the oid of a tuple are accessible in
>                 the row. There must be  no  whitespaces  between  the
>                 classname, the percent and the ROWTYPE keyword.
>
>             <name> RECORD;
>
>                 Records  are  similar  to  rowtypes, but they have no
>                 predefined structure and it's impossible to assign  a
>                 value  into them. They are used in selections and FOR
>                 loops to hold one actual database tuple from a select
>                 operation.  One  and  the  same record can be used in
>                 different selections (but not in nested ones).

Do we really need in both ROWTYPE & RECORD ?
I would get rid of RECORD and let ROWTYPE variables be
'with yet undefined type of row' (make <class> optional). More of that,
why not treat ROWTYPE like structures in C and let the following:

name %ROWTYPE {a    int4, b text};

?

>                 SELECT * INTO myrec FROM EMP WHERE empname = myname;
                                ^^^^^                          ^^^^^^
How about $-prefix ?

>             As indicated above there is an ELOG  statement  that  can
>             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 are used in Oracle, Sybase etc here ?

Vadim