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

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
additionto 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
thattype           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.
Cursorsused   inside of functions only don't need  transaction  blocks.  Of   course, they'll not survive the current
transactionsend, but   if funcA() creates a cursor and then  calls  funcB(refcursor)   with it, there does not need to
bea 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
implicitcursors   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
happensa  statement  is   half way done and the only way to cleanup is rolling back the   entire transaction (for now,
Vadimis 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@Yahoo.com #



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