Re: [HACKERS] PL/pgSQL - for discussion

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