From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | "Johnny Jrgensen" <pgsql(at)halfahead(dot)dk>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: PL/pgSQL loops? |
Date: | 2001-11-29 06:08:36 |
Message-ID: | 15769.1007014116@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> Something like the below seemed to make it work for me under
> 7.2b3:
Oh ... duh! I've been bit by that before myself. In the original,
since the FOR loops were using integer variables (not record or rowtype
variables as they should've), the plpgsql parser was expecting an
integer FOR-loop. Which goes like
FOR ivar IN expression .. expression LOOP stmts END LOOP;
Evidently, somewhere around the END LOOP it realized that it was missing
the .. part of the construct.
I've mumbled before that it's bad form to be using the declared type
of the FOR variable to drive the syntaxing of FOR loops --- poor error
recovery and unhelpful error messages are exactly the reasons why.
Not sure that this can easily be fixed, however.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-11-29 06:15:08 | Re: Return Opaque / Error in Function |
Previous Message | Tom Lane | 2001-11-29 05:02:01 | Re: distinct() vs distinct on () |