Re: BUG #1215: Call sql function from plpgsql results vary. - Mailing list pgsql-bugs

From Robert Henkel
Subject Re: BUG #1215: Call sql function from plpgsql results vary.
Date
Msg-id BAY9-F57hsM8qIPsD2F0001bee1@hotmail.com
Whole thread Raw
In response to BUG #1215: Call sql function from plpgsql results vary.  ("PostgreSQL Bugs List" <pgsql-bugs@postgresql.org>)
List pgsql-bugs
That fixed it, it works now as I had hoped. Thanks again


>From: Tom Lane <tgl@sss.pgh.pa.us>
>To: "Bob Henkel" <bob@teamhenkel.com>
>CC: pgsql-bugs@postgresql.org
>Subject: Re: [BUGS] BUG #1215: Call sql function from plpgsql results vary.
>Date: Wed, 11 Aug 2004 23:06:09 -0400
>
>"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> > I was playing around seeing what new things I could do in stored
>procedures.
> > Here is the statment I'm using to get the issue.
> > select * from f_trap_error();
> > I expect the above statement to alway return 1 which it does.
> > The issue is I expect the trapped_error table to contain a seq id and
>than a
> > 999 899
>
>I think the problem is you declared f_test_sql as IMMUTABLE, which
>entitles the planner to execute it once and bind the result as a
>constant.  Functions with side-effects should *never* be marked
>immutable (nor stable for that matter).
>
>            regards, tom lane

pgsql-bugs by date:

Previous
From: anthony.caduto@micorp.com
Date:
Subject: pg_restore many errors
Next
From: Martin Münstermann
Date:
Subject: Re: 8.0.0beta1: -lpthread missing