Re: [HACKERS] PL/pgSQL - for discussion

Vadim wrote:
>
> 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.

    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.

    The  typing  of  the  procedure body inside of ' is damned. I
    know :-) I think it might be possible to allow {} or the like
    to  be  used  instead and then only quote \} inside the body.
    This stuff might be easy done in the scanner (haven't  looked
    at the code yet).

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

    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.

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

    Right now!

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

    Hmmm. Or doing it the Oracle way

        DECLARE
          TYPE myrectype IS RECORD (
            field1  integer NOT NULL,
            field2  text);

          myrec   myrectype;
        BEGIN
          ...
        END

    But I would like to let the RECORD of  unspecified  structure
    in.  It doesn't need much declarations typing.

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

    I  don't  like  the  $'s.  But  I  have seen the problem that
    without blowing up my parser I cannot do it  the  oracle  way
    where  a  field  name  of  a  selected table precedes a local
    varname and the  local  varname  if  identical  to  a  tables
    fieldname  must be prefixed with the label of the block. This
    is what Oracle does:

        <<outer>>
        DECLARE
          emp emp%ROWTYPE;
          empname  emp.empname%TYPE
          salary   emp.salary%TYPE
        BEGIN
          ...
          SELECT * INTO outer.emp FROM emp WHERE empname = outer.empname;
          --            ^^^^^^^^^      ^^^       ^^^^^^^   ^^^^^^^^^^^^^
          --            PLs rowtype    table     table-    PLs variable
          --                                     field

          salary := emp.salary;
          -- ^^^^^^^^^^^^^^^^^
          -- Outside of SELECT stmt - all identifiers in PL

          ...
        END


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

    Oracle uses RAISE EXCEPTION ... with some numbers  specifying
    the message in the message catalog and other information.

    What about

        RAISE EXCEPTION 'format' [identifiers];     -- elog(ERROR, ...)
        RAISE NOTICE 'format' [identifiers];        -- elog(NOTICE, ...)
        RAISE DEBUG 'format' [identifiers];         -- elog(DEBUG, ...)

    The  first  is somewhat compatible and the two otheres can be
    easyly  commented  out.  Since  the  language   is   somewhat
    PostgreSQL   specific   anyway  (arguments  are  unnamed  and
    identified by position with $n), PL procedures must be ported
    when  moving to another DB. But who ever wants to use another
    DB, once he used PostgreSQL?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #