Hi hackers,

Is there a technical reason we do not set the value of FOUND when
executing a dynamic statement in plpgsql?

It seems surprising that FOUND is set by SELECT, PERFORM, UPDATE,
INSERT, DELETE, etc, *except* when those statements are invoked by
EXECUTE.

I had a brief look at the code in pl/plpgsql/src/pl_exec.c, and
couldn't see any screamingly obvious reasons not to set FOUND in
exec_stmt_dynexecute in much the same way we do in exec_stmt_execsql.

Thanks for your time,
BJ

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, 2007-10-16 at 11:24 +1000, Brendan Jurd wrote:
> Is there a technical reason we do not set the value of FOUND when
> executing a dynamic statement in plpgsql?

See prior discussion:

http://archives.postgresql.org/pgsql...0/msg00001.php

It would be easy enough to have EXECUTE modify FOUND, and that might
well be worth doing. Adding an "EVAL" concept would also be useful,
though, and would avoid changing EXECUTE's behavior in a way that might
break client apps.

-Neil



---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On 10/16/07, Neil Conway <neilc@samurai.com> wrote:
> See prior discussion:
>
> http://archives.postgresql.org/pgsql...0/msg00001.php

Thanks for the link. I did search the archives but unfortunately
terms like 'found' and 'execute' generate a lot of unwanted matches =)

>
> It would be easy enough to have EXECUTE modify FOUND, and that might
> well be worth doing. Adding an "EVAL" concept would also be useful,
> though, and would avoid changing EXECUTE's behavior in a way that might
> break client apps.

Hm, it seems the only thing that would be broken is a function which
runs an ordinary statement, and then waits until *after* doing an
EXECUTE to check the value of FOUND. It's tough to imagine somebody
actually relying on this behaviour, and perhaps it's fair to say that
failure to check FOUND immediately after the statement you're
interested in is bad coding practice?

Regards,
BJ

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

2007/10/16, Neil Conway <neilc@samurai.com>:
> On Tue, 2007-10-16 at 11:24 +1000, Brendan Jurd wrote:
> > Is there a technical reason we do not set the value of FOUND when
> > executing a dynamic statement in plpgsql?
>
> See prior discussion:
>
> http://archives.postgresql.org/pgsql...0/msg00001.php
>
> It would be easy enough to have EXECUTE modify FOUND, and that might
> well be worth doing. Adding an "EVAL" concept would also be useful,
> though, and would avoid changing EXECUTE's behavior in a way that might
> break client apps.
>
> -Neil
>
>

It's symply. But other execute statement only will more uglyze plpgsql.

use GET DIAGNOSTICS statement a wait for sql/psm

Pavel

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq