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(at)debis(dot)com (Jan Wieck) #