Josh Berkus wrote:
> This brings up an important point. We have a medium-large user base for
> PL/pgSQL out there, but it appears that Jan Wieck no longer has time to
> develop the language ... nor should he be the sole developer. Howe do
> we find more developers to expand & extend PL/pgSQL? I
> I'm happy to do my bit on the documentation side, but I don't want to end
> up duplicating the cookbook - does anyone know the status of this? I'd
> guess 90% of plpgsql functions will be on the same "theme" as something
> in a cookbook so it's the perfect format for learning/cut & paste.
I
On 3/14/01, 4:28:03 PM, Josh Berkus <[EMAIL PROTECTED]> wrote regarding Re:
[SQL] PL/pgSQL "compilation error":
> Tim,
> > Hello all - I apologize for the newbie-esque question, but the debug
output
> > from postgres when you have a bug in your PL/pgSQL pr
Bruce Momjian writes:
> There is a PL/PgSQL HowTo that we are trying to integrate into the docs
> for 7.1. Anyone have a URL or status on that?
It's not a PL/pgSQL Howto, it's just a documentation how to port from
Oracle's PL/SQL. The status is "done". The author expressed interest in
more wo
> Bruce Momjian writes:
>
> > There is a PL/PgSQL HowTo that we are trying to integrate into the docs
> > for 7.1. Anyone have a URL or status on that?
>
> It's not a PL/pgSQL Howto, it's just a documentation how to port from
> Oracle's PL/SQL. The status is "done". The author expressed inter
From: "Tim Perdue" <[EMAIL PROTECTED]>
> Hello all - I apologize for the newbie-esque question, but the debug
output
> from postgres when you have a bug in your PL/pgSQL procedure is none to
> detailed.
>
> I've created the following procedure and am getting an error when I try to
> update the ta
> IF NEW.status_id <> OLD.status_id THEN
> IF new.status_id = 1 THEN
> UPDATE artifact_counts_agg SET open_count=open_count+1 \
>WHERE group_artifact_id=new.group_artifact_id;
> ELSE IF new.status_id = 2 THEN
> UPDATE artifact_counts_
Tim,
> Hello all - I apologize for the newbie-esque question, but the debug output
> from postgres when you have a bug in your PL/pgSQL procedure is none to
> detailed.
It's an improvement over the query parser errors -- at least in
PL/pgSQL you get a line number! Although in your case, the l
On Wed, Mar 14, 2001 at 10:33:49AM -0500, Bruce Momjian wrote:
> It is hard to test this without the table schema, but I think you are
> missing some END IF's in the code above. Those are not elif's, but
> actual new IF's that need their own END IF, I think.
Oh wow - this is almost like going ba
Don't you have one END IF too many?
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
> Don't you have one END IF too many?
No you don't ... I can't count this morning :-(
Weird. I don't see what's wrong either. Anyone?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once wi
> On Wed, Mar 14, 2001 at 10:33:49AM -0500, Bruce Momjian wrote:
> > It is hard to test this without the table schema, but I think you are
> > missing some END IF's in the code above. Those are not elif's, but
> > actual new IF's that need their own END IF, I think.
>
> Oh wow - this is almost l
Hello all - I apologize for the newbie-esque question, but the debug output
from postgres when you have a bug in your PL/pgSQL procedure is none to
detailed.
I've created the following procedure and am getting an error when I try to
update the table. The error is something like "parse error near
13 matches
Mail list logo
