Re: Grammar-problems with pl/pgsql in gram.y

Klaus Reger wrote:
> Am Mittwoch, 16. Mai 2001 16:10 schrieb Jan Wieck:
> > Here it is. stmt_else is defined as type <stmts>, not <stmt>.
> > The PLpgSQL_stmt_if struct has a condition query and two
> > statement lists (type <stmts>). You're trying to put a single
> > statement into the else part instead of a list of statements.
> Thank you for the hint! That was it.
>
> > Maybe it'll work if you surround it with another
> > PLpgSQL_stmts struct where your new PLpgSQL_stmt_if is the
> > only statement in it's list. Since I have some bigger work
> > outstanding for PL/pgSQL, send the resulting patch (if you
> > get it to work) directly to me.
> The patch follows this message. May you tell me what kind of work it is,
> cause I'm so curous :-). By the way, the next thing I try is a
> EXCEPTION WHEN OTHER-clause, like in Oracle. Let's look if I'm successful.

complete CURSOR support. With some enhancements in SPI plus a
little fix in ProcessPortalFetch() I have up to now

Explicit CURSOR:

DECLARE
<cursor_name> CURSOR [(<arg> <type> [, ...])]
IS <select_statement>;

The select statement can use any so far declared
variable or functions arguments in addition to the
optional cursor arguments. These will be evaluated at
OPEN time.

There is a new datatype 'refcursor'. The above
declaration will create a local variable of that type
with a default "value" of the variables name. This
"value" will be used for the global cursors name
during OPEN.

BEGIN
OPEN <cursor_name> [(<expression> [, ...])];

FETCH <cursor_name>
INTO {<record> | <row> | <var> [, ...]};

CLOSE <cursor_name>;

The FETCH command sets the global FOUND variable, so
a typical loop over a resultset looks like

LOOP
FETCH mycur INTO myrec;
EXIT WHEN NOT FOUND;
-- Process the row
END LOOP;

Reference CURSOR:

DECLARE
<cursor_name> REFCURSOR [ := <string> ];

BEGIN
OPEN <cursor_name> FOR <select_statement>;

OPEN <cursor_name> FOR EXECUTE <string>;

The new datatype 'refcursor' can be used to pass any cursor
around between functions and the application. Cursors used
inside of functions only don't need transaction blocks. Of
course, they'll not survive the current transactions end, but
if funcA() creates a cursor and then calls funcB(refcursor)
with it, there does not need to be a transaction block around
it.

What I need to do now is fixing some memory allocation issues
in PL/pgSQL and move FOR loops to use implicit cursors
internally. Your patch looks like it doesn't conflict with
any of my work. I'll commit it soon.

For the EXCEPTIONS thing, well that's another issue. We could
of course simulate/generate some of the exceptions like "no
data found" and the other one I forgot (telling that a SELECT
INTO returned multiple results). But we cannot catch a
duplicate key error, a division by zero or a referential
integrity violation, because when it happens a statement is
half way done and the only way to cleanup is rolling back the
entire transaction (for now, Vadim is working on savepoints).
So I suggest you don't spend much of your time before we have
them.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com